Collaborative electronic game play employing player classification and aggregation

ABSTRACT

A method and system tracks, analyzes or sorts behaviors of user or players across a network to draw correlations from, or characterizations of, those user or players and identifies similarly characterized or mutually complementary user or players. For example, the method automatically obtains player data regarding interactions by each of multiple players with a multiplayer electronic game via each player&#39;s corresponding data processing device connected via the network. The method can then sort, classify or suggest additional activities, games, groups, or other different activities or actions for the players.

CROSS-REFERENCE TO RELATED APPLICATIONS

Any and all applications for which a foreign or domestic priority claimis identified in the Application Data Sheet, or any correction thereto,are hereby incorporated by reference into this application under 37 CFR1.57.

BACKGROUND

Many types of games or group-based challenges exist, such as boardgames, card games, domino/tile games, pen and pencil games, guessinggames, dexterity/coordination games, business games, sports, and soforth. Games are inherently social, and many players like to play gamesfor the challenge of the game. However, many players also enjoy thesocial aspect of gaming, and the ability to meet up to interact withother players. One type of game is a role-playing game (RPG), which is abroad family of games where players assume the roles of characters in afictional setting. For example, a player may assume the role of a magein a fantasy-themed role-playing game and partake in various gameinteractions such as befriending other characters, battling monsters,completing quests, building and/or trading items, and so on. Actionstaken within the game succeed or fail according to a formal system ofrules and guidelines. The original forms, sometimes called pen-and-paperRPGs, are conducted through speech, whereas in live action role-playinggames (LARPs), players physically perform their characters' actions. Inboth forms, a director (game master (GM)) usually decides on rules andsettings to be used and acts as referee, while other players play therole of one or more characters in the game.

Computer-assisted gaming has been used to add elements of computergaming to in-person and pen and paper role-playing. In these games,computers are used for record-keeping and sometimes to resolve combat,while the participants generally make decisions concerning characterinteraction. Several varieties of RPG also exist in primarily electronicmedia, including multi-player text-based multi-user dungeons (MUDs) andtheir graphics-based successors, massively multiplayer onlinerole-playing games (MMORPGs). Role-playing games also includesingle-player offline role-playing video games in which players controla character or team who perform game interactions (e.g., competing inbattle, conversing with other players or characters, partaking inquests, trading with merchants, etc.), and whose capabilities advanceusing statistical mechanics. These games often share settings and ruleswith pen-and-paper RPGs, but generally emphasize character interactionand/or advancement more than collaborative storytelling.

MMORPGs, such as Blizzard Entertainment's World of Warcraft, Sony OnlineEntertainment's EverQuest, or Jagex Games Studio's RuneScape, combinethe large-scale social interaction and persistent world of MUDs withgraphical interfaces. A persistent world is a virtual world thatgenerally continues to exist even after a user exits the world.User-made changes to its state are, to some extent, permanent. Servers,data structures, algorithms, etc. associated with the persistent worldgenerally remain available and operational for the user, or other usersfrom around the world, to join and interact with the persistent worldand with other players at any time of day or night. For example, if acharacter purchases an item from a merchant or some way adds an item tothe character's inventory in a persistent virtual world, one or moredata structures associated with the persistent virtual world may becreated or modified to reflect the addition. Most MMORPGs do notactively promote in-character role-playing; however, players can use thegames' communication functions to role-play, which they may do tovarying extents.

More generally, a massively multiplayer online game (also called MMOG orMMO) is a multiplayer video game which is capable of supporting hundredsor hundreds of thousands of players simultaneously, and need not be ofthe RPG type, but can be applied to any competitive or cooperativeendeavor. An MMOG is generally played on a computer network such as theInternet, and features at least one persistent virtual world. In somecases, multiple instances of a persistent virtual world may bemaintained for the MMOG. Each instance may be governed by a differentset of rules or conventions, may be available to different regions ofthe world. Some MMOGs are designed as a multiplayer browser game toreduce infrastructure costs and use a thin client. They are, however,not necessarily games played on personal computers. Most of the newergame consoles, including the PSP and PlayStation 3 by Sony, Xbox 360 byMicrosoft, and DSi and Wii by Nintendo can access the Internet and maytherefore run MMO games. Additionally, mobile devices and smartphonesbased on such operating systems as Windows Mobile, Apple's iOS, andGoogle's Android, as well as the Apple iPhone and iPad, are seeing anincrease in the number of MMO games available.

Multiplayer games and networked activities, such as MMOGs and MMORPGs,enable players to cooperate and compete with each other on both a smalland large scale, and sometimes to interact meaningfully with peoplearound the world. They include a variety of game-play types,representing many video game genres. Examples of game-play typesinclude, but are not limited to:

-   -   Massively Multiplayer Online First Person Shooter (MMOFPS) is a        subset of popular first-person shooter-type games where a player        views an environment or virtual world through the eyes of a        character. MMOFPS is an online gaming genre which typically        features a world (e.g., persistent world) and a large number of        simultaneous players in a first-person shooter fashion. These        games provide large-scale, sometimes team-based combat. The        addition of persistence in the game world means that these games        add elements typically found in RPGs, such as experience points.        However, MMOFPS games generally emphasize player skill more than        player statistics, as no number of in-game bonuses will        compensate for a player's inability to aim and think tactically.    -   Massively Multiplayer Online Real-Time Strategy Games (MMORTS)        often combine real-time strategy (RTS) with a persistent world        though in some cases worlds are “instanced” for the duration of        a game, a match, a tournament, or other specified time period.        Players may assume the role of a general, king, or other        figurehead leading an army into battle while maintaining the        resources needed for such warfare. The titles are often based in        a science fiction or fantasy universe and are distinguished from        single or small-scale multiplayer RTSes by the number of players        and, in some cases, common use of a persistent world. The world        is generally hosted by the game's publisher and, in the case of        persistent worlds or an “instanced” world of longer duration,        continues to evolve even when the player is offline.    -   Massively Multiplayer Online Sports Games allow players to        compete in more traditional sports, such as soccer, basketball,        baseball, hockey, golf or football.    -   Massively Multiplayer Online Racing (MMOR) is a large, online        racing game, although some games may include elements of combat.    -   Massively multiplayer online rhythm games (MMORGs), or massively        multiplayer online dance games (MMODGs), are MMOGs that are also        music video games, for example those which were influenced by        Dance Dance Revolution by Konami.    -   Massively multiplayer online management games (MMOMGs) are often        considered easy to play and don't take much time; a player logs        in a few times each week, sets orders for an in-game team and        finds how to defeat fellow players. Other management games, such        as The Sims Online by Electronic Arts and Monopoly City Streets        by Tribal DDB, require taking control of people.    -   Massively Multiplayer Online Social Games focus on socialization        instead of objective-based game-play. There is a great deal of        overlap in terminology with “online communities” and “virtual        worlds”. One example is Linden Labs' Second Life, which        emphasizes socializing, world-building, and an in-world virtual        economy that depends on the sale and purchase of user-created        content. Instead of being based around combat, it is based        around creating or acquiring virtual objects, including models        and scripts.    -   Some MMOGs have been designed to accurately simulate certain        aspects of the real world. They tend to be very specific to        industries or activities of very large risk and huge potential        loss, such as rocket science, airplanes, trucks, battle tanks,        submarines etc. The MMOG genre of air traffic simulation is one        example, which provides rigorously authentic flight-simulation        environments to players in both pilot and air traffic controller        roles. In this category of MMOGs, the objective is to create        duplicates of the real world for people who cannot or do not        wish to undertake those experiences in real life. For example,        flight simulation via an MMOG requires far less expenditure of        time and money, is completely risk-free, and is far less        restrictive (fewer regulations to adhere to, no medical exams to        pass, and so on).    -   MMO turn-based strategy games, such as Steve Jackson Games'        UltraCorps allow numerous players to share a common playing        field. Turns are usually time-based, with a “tick” schedule        usually daily. All orders are processed, and battles resolved,        at the same time during the tick.    -   Alternate reality games (ARGs) can be massively-multiplayer,        allowing thousands of players worldwide to co-operate in puzzle        trails and mystery solving. ARGs may take place in a unique        mixture of online and real-world play that usually does not        involve a persistent world, and are not necessarily multiplayer,        making them sometimes seen as somewhat different from MMOGs.    -   Casual or “Quick fix” MMOGs, such as Racing Frogs by Wacky Web        Fun Ltd. and logen Ltd., are MMOGs that can be played with only        a small amount of time every day, week, month, etc.    -   Massively multiplayer collectible card games, such as Magic: The        Gathering Online, include unique virtual objects used within a        game that may be exchanged between players within the game or on        a secondary market.    -   A blended MMO game incorporating features of various game-play        types described above or other contemplated game-play types.

Some attempts to build peer-to-peer (P2P) MMOGs have been made; however,so far most of these efforts appear to be academic. A P2P MMOG maypotentially be more scalable and cheaper to build, but notable issueswith P2P MMOGs include security and consistency control, which can bedifficult to address given that clients are easily hacked.

Some attempts have been made to provide ways to connect geographicallydisbursed players together in a given game or networked activity. Forexample, Microsoft's Xbox Live allows players to enter existing gamesand be joined together to participate in a game, even if the playershave had no prior contact with each other. Blizzard Entertainmentemploys a dungeon finder tool and battlegrounds matchmaking functionthat connect players within its World of Warcraft game. Under thedungeon finder tool or using the battlegrounds matchmaking function,players can select from various dungeons or battlegrounds, where playerscan be linked based on their class or geographic region, such as withinthe U.S./Canada, Latin America, etc., however, this matchingfunctionality is quite rudimentary. Starcraft provides a player finderboard that lists players, points obtained, game faction, numbers of winsand losses (with win percentage), achievement points and division. Newplayers can attempt to find a compatible player within whom to play thegame from the board. These player matching systems, however, fail toprovide adequate matching to enhance player experiences, among othershortcomings. Other services provide information regarding playercharacter equipment. For example, the GearScore software providesmetrics for various items of player equipment permitting players tocompare certain relative equipment levels between characters.

Some attempts have also been made to track user activities in an effortto improve user efficiency. For example, RescueTime automated timetracking and management software by RescueTime, Inc. tracks processesexecuting on a user's client computer to determine how a user's time isspent and employs an alert system to notify users based on datacollected. The system, however, is focused on improving user efficiencyrather than identifying matches or otherwise characterizing users.

Overall, as given the variety of games and the ever increasing need toenhance each player's experience, there is a need to further improveMMOGs.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a block diagram illustrating an example of a networked gamingsystem in which aspects of the invention may be employed.

FIG. 1B is a block diagram illustrating examples of client devices thatmay access and use the gaming system.

FIG. 2 is an example of a screen display showing character equipment,statistics and other data associated with a player's character in agame.

FIG. 3 is an example of a screen display showing a game and variousmenus and display panels of information.

FIG. 4 is an example of a screen display showing a map for use in thegame of FIG. 3.

FIG. 5A is a block diagram illustrating an example of a packet exchangedwithin the gaming system of FIG. 1A.

FIG. 5B is an example of an exchange of packets between clients and gameservers via a network.

FIG. 6A is a block diagram illustrating various system architectures forthe gaming system at FIG. 1A.

FIG. 6B is a block diagram illustrating an example of a packet parserand analyzer.

FIG. 6C is a block diagram illustrating use of a portal server andaccess to additional online resources.

FIG. 7 is an example of a profile data structure for recording andmanaging player and character data.

FIG. 8 is an example of a user interface to permit a player to providepersonal gameplay preferences.

FIG. 9 is a screen or GUI to permit a player to input preferences.

FIG. 10 is a screen or GUI to permit a player to providepost-game/session/quest responses.

FIG. 11 is a flow diagram illustrating an example of a process forgenerating a player data structure.

FIG. 12 is a flowchart illustrating an example of a routine forgathering gameplay data.

FIG. 13A is a flowchart illustrating an example of a routine fordetermining player characteristics.

FIG. 13B is a flow chart illustrating an example of a subroutine foranalyzing movement data.

FIG. 13C is a flow chart illustrating an example of a subroutine foranalyzing communications data.

FIG. 13D is a flow chart illustrating an example of a subroutine foranalyzing player input and responses thereto.

FIG. 14A is a flow diagram illustrating an example of a routine forestablishing a new game/quest/endeavor with multiple players.

FIG. 14B is a graph showing an example of peak load on servers.

FIG. 14C is a flow diagram illustrating an example of a routine forconserving resources.

FIG. 15 is a flow diagram illustrating an example of a routine formatching players.

FIG. 16 is a flow diagram illustrating an example of determiningequipment weighting totals.

FIG. 17A is a flow diagram illustrating an example of a process foremploying pre-qualified virtual worlds.

FIG. 17B is a flow diagram illustrating an example of a process toqualify players to enter new pre-qualified virtual worlds.

The headings provided herein are for convenience only and do notnecessarily affect the scope or meaning of the claimed invention.

DETAILED DESCRIPTION Overview and Definitions

Various examples of the invention will now be described. The followingdescription provides certain specific details for a thoroughunderstanding and enabling description of these examples. One skilled inthe relevant technology will understand, however, that the invention maybe practiced without many of these details. Likewise, one skilled in therelevant technology will also understand that the invention may includemany other obvious features not described in detail herein.Additionally, some well-known structures or functions may not be shownor described in detail below, to avoid unnecessarily obscuring therelevant descriptions of the various examples

The terminology used below is to be interpreted in its broadestreasonable manner, even though it is being used in conjunction with adetailed description of certain specific examples of the invention.

Discussed in detail herein is a system that permits multiple users orplayers to interact, e.g., in an MMOG, while enjoying enhancedfunctionality. As used herein, the terms user and player are usedinterchangeably to indicate individuals engaging in one or morenetworked activities such as an MMOG or other activity as describedherein. While generally described herein as server-based, a peer-to-peersystem or a node-based system may also be employed, as well as othersystems that permit geographically distributed players or users tointeract and pursue goals. Further, aspects of the invention aredescribed herein with respect to an MMOG, and specifically afantasy-based MMORPG, although the invention applies to any type orgenre of game or networked activity. Indeed, the invention may apply notonly to games, but to any networked computing or data processing system.For example, the system may provide a matchmaking service forindividuals based on their shopping habits, common or similar interestsor hobbies, travel plans, etc. The system may identify similar usersbased on common online activity with respect to viewing online articles,booking travel tickets via an online travel website, booking a hotel inthe same city, and so on. Furthermore, the system can identify groups ofusers who may be interested in purchasing a product or service, and thusthe system may be able to identify, negotiate or provide a groupdiscount for the product/service to the identified group, as describedherein.

Moreover, the invention need not be limited to massively-multiplayeronline activities, but can be applied to one-on-one endeavors, such aswhere two people interact with a program to share information, achieveresults, pursue goals, or perform other actions. The example providedherein of a MMORPG is used only as an example to help illustrate aspectsof the invention, and those skilled in the art will readily recognizethat these aspects of the invention can apply to not only other types ofelectronic games, but to any network activity involving two or moreindividuals. Similarly, the system described herein is applicable to anyuser, not necessarily players in a game. Thus, while the term “player”is used generally in the following description, that term is intendedherein to represent any user or group of users.

Furthermore, as described herein, the invention permits conservation ofresources, such as reducing, adjusting or optimizing the number ofactive servers in a network system that provide access to the game orother online endeavor. As described herein, in some embodiments, thesystem can forecast usages and power down servers to conserve energy,and consolidate players to remaining servers, thereby limiting thenumber of servers required. Further, players can be rated orcharacterized based on their determined power consumption or energyfootprint, for example their calculated kilowatt usage, and the systemmay even provide signaling to clients so as not to have a constantlypowered on computer, game console or other device. Moreover, the systemcan provide incentives and/or disincentives to users to encourage gameplay during off-peak hours to balance load, reduce wear on resources,reduce a number of servers needed during peak hours, etc. Furtherdetails are provided herein.

As described more fully below, the system permits automatedclassification of players to enhance user or player interactions and/orpromote system hardware power efficiencies, etc. The system describedherein permits the automated matching or identifying of players based onthe classification, with a graphical user interface (GUI) to permitplayers to adjust criteria for the classification. The system permitsequipment weighting to help match players, e.g., based on virtualequipment held by each player's character(s) in a game. This system may,for example by employing pre-qualified virtual worlds, permit players tomove between worlds, even temporarily, without losing experience,equipment or both. Furthermore, the system may match players with games,worlds, servers, players, in-game activities, etc. based onclassification data generated by and/or provided to the system. Thesystem may also suggest or recommend products, activities, games,quests, etc. to users based on their individual actions, activities, orother user characteristics or metrics determined by the system.

Aspects of the invention described herein monitor user or playerbehavior and identified characteristics, generate metrics, and therebyclassify players to perform improved matching or other functions.Generally, the system identifies, determines, analyzes, and/or performscalculations regarding various items of information and/or dataassociated with users and user characters including characteristics,metrics, criteria, classifications, attributes, etc.; as used herein,the terms characteristics, metrics, criteria, classifications, andattributes are used interchangeably to reference information or dataassociated with users and user characters for the purposes describedherein. For example, the system analyzes gameplay of individual playersto generate a rich set of data based on certain player actions. In someembodiments, the system automatically identifies, analyzes, anddetermines, with computer hardware comprising one or more computerprocessors, player actions and/or characteristics and transforms theseidentified player actions and characteristics to generate certaincriterion associated with players, for example to aid in playercharacterization, matching, etc. as further described herein. Theseactions can include movements within a game (such as places visited),tactics employed during battle or competitions (e.g., types and order ofspells used), communications made between players (e.g., vocabulariesand grammar of text communications between players), etc. These actionscan also include those that take place outside a game such as trackingindividuals via GPS coordinates or via other means to determinelocations frequented and activities engaged in generally. The systemalso analyzes characteristics of users or their avatars to generate,enrich, and/or otherwise modify this data set. For example, the systemmay identify a user's or avatar's age, sex, race, education level,income, level, class, relative equipment level or strength, abilities,and other similar items. Based on this rich data set, the systemtransforms the data set, for example by generating metrics for players,such as experience points generated per hour, gold acquired per hour,average sentence length, average number of spelling errors or cursewords per communication, time period, distance traveled, average numberof locations visited per game session, preferred activities, preferredlocations, and other metrics described herein. These metrics helpcharacterize and quantify a particular player's gameplay style andtherefrom infer behavioral or personality traits of the player, forexample to thereby automatically and more accurately match that playerwith other players, thereby providing an overall enjoyable gamingexperience. Transformation may be accomplished, for example, byperforming a lookup and comparing certain user actions orcharacteristics against averages for other players to produce a metricfor a particular player, performing calculations on elements of the dataset to generate new metrics for a particular player, etc. Thus, in oneembodiment, the system identifies one or more characteristics of a firstuser of the networked computer game; automatically identifies, withcomputer hardware comprising one or more processors, one or more actionsperformed by the first user; determines a first criterion based on theone or more characteristics of the first user and the one or moreactions performed by the first user; associates the first criterion withthe first user; identifies one or more characteristics of a second userof the networked computer game; automatically identifies, with computerhardware comprising one or more processors, one or more actionsperformed by the second user; determines a second criterion based on theone or more characteristics of the second user and the one or moreactions performed by the second user; associates the second criterionwith the second user; analyzes the first criterion and the secondcriterion to determine a relationship between the first criterion andthe second criterion; creates an association between the first user andthe second user based at least in part on the relationship between thefirst criterion and the second criterion; and, provides the first user,based at least in part on the association, an option related to anetworked computer game. As described further herein, the option to thefirst player may relate to the first networked computer game or to otherdifferent networked computer games.

Importantly, and as noted frequently herein, the invention is notlimited for use in MMOGs, or indeed to any games, but can be applied toany network interaction between two or more users. Thus, aspects of theinvention may monitor the interaction of a user to an online activity orendeavor, extract a rich data set from that activity, generate metricstherefrom, and thereby classify or otherwise determine behavioral traitsfor that user so that that user may be accurately matched with otherusers in future online or networked interactions by that user in thesame or similar online or networked endeavors or activities.

As described herein, the system characterizes users who are undertakingan endeavor or activity via data processing devices, where the dataprocessing devices are connected via a data network. The system obtainsdata regarding the user's interactions with a software applicationassociated with the endeavor or activity. The system then analyzes thedata regarding the user's interactions with the software application,and, based on the analyzing, characterizes the user's behaviors,propensities and/or affinities/dislikes. The system can furtherdetermine at least one quantifiable metric or statistic from the dataregarding the user's interactions with the software application, and canmatch the user with at least one other user having similar or otherwisecomplementary behaviors, propensities or affinities/dislikes as theuser.

In general, brief definitions of several terms used herein are providedbelow or preceded by the term being enclosed within double quotationmarks. Such definitions, although brief, will help those skilled in therelevant art to more fully appreciate aspects of the invention based onthe detailed description provided herein. Such definitions are examplesonly and are not limiting, but are instead used with respect to variousembodiments or examples of the invention described herein, and suchdefinitions are further defined by the description of the invention as awhole (including the claims) and not simply by such definitions.

Ability—special actions a character can take or perform to interact withthe game.

Auction or Auction House (AH)—a place or web site where real goodsand/or virtual goods obtained in a game or elsewhere can be sold ortraded between players through an automated merchant/auction systemoften within the game; third party sites often permit the purchase andsale of virtual goods for real world currency, rather than for in-gamecurrency such as gold or points.

Avatar—a representation of a user's character, persona, or other alterego that is generally, but not always, displayed graphically.

Buff/Debuff—a temporary effect that raises or improves (buff) or lowers(debuff) a statistic or attribute. In some embodiments, these effectsinclude real world effects, for example a shopping buff endowing a userwith a certain discount on the price of one or more items or providingaccess to a store or other location at a specified time such as an afterhours or private sale.

Clan—a player-formed organization that may facilitate or representteamwork among the players, or may simply be an association of players.Clans may be associated with a plurality of games and clan activitiesmay also take place in the real world as well as in the virtual or gameworld.

Class—an association or description of a player or character, such as ajob or profession, which may determine or influence some or all of theirskills and abilities. A wide variety of classes are possible dependingon the specific game or activity. For example, classes in certainfantasy and other MMOGs include healers who can heal damage of a group,tanks who hold the attention or aggression of an opponent, “DPSers”(Damage Per Second) who generally inflict relatively high amounts ofdamage during battle, buffers who can increase abilities of the group,and crowd controllers who can manage aggression of a group of opponents.

Critical Hit—a hit that inflicts bonus damage; characters may have acritical hit rating representing a percent chance to deal a criticalhit.

Damage over Time (DoT)—an effect that deals damage over a period oftime.

Damage Per Second (DPS)—a calculation of damage done per second, whichcan refer to a certain type of class or player, and often referring to acharacter capable of dealing high damage per second in combat, but whichmay have certain weaknesses, such as low hit points, armor class, orboth. DPS may also refer to the combat efficiency of an item expressedas damage per second.

Experience Points—points to represent a character's experience generallyawarded based on activities. Experience points allow a character toadvance through a progression of levels, receive improved statistics,obtain more abilities, etc.

Faction—a group or organization of NPCs for which a character canperform quests or tasks to improve standing or reputation with thatfaction; some factions are opposed, so that gaining reputation with onefaction lowers reputation with another.

Grinding—engaging in a repetitive activity to generate experiencepoints, money, or items in an efficient manner by a player.

Group—a number of players who formally join forces to complete sharedgoals, and which typically share experience points, loot, rewards, etc.

Guild—See Clan.

Level—In level based games, a character's level is an abstractrepresentation of how powerful or experienced the character is, wherebya higher level character is generally more powerful or more experienced,has more or stronger abilities, or can obtain or be equipped with awider range of items than a lower level character.

Mobile Object (Mob)—generally, an aggressive being controlled by thegame, such as a monster.

Non-Player Character (NPC)—generally, a non-aggressive being controlledby the game, such as an innkeeper, merchant, guard, villager, etc.

Raiding—a type of gameplay generally requiring multiple parties orgroups of players, often requiring planning, coordination, and teamworkto accomplish shared goals within a game such as combining to kill amonster, claim a territory or portion of a map, etc.

Resistance—an ability to reduce incoming damage of a certain type, suchas damage from fire-based or acid-based attacks, often represented as apercent reduction in damage from that type of attack.

Specialization—the ability of a player to improve certain abilities orother aspects of her character, often at the expense of other abilitiesor aspects.

Statistics—a numerical representation of core attributes of a character,such as strength, intelligence, coordination, etc. Statistics are oftenused to algorithmically determine success of actions, attributes such astotal health, total mana, chance to critically hit, etc.

Tank—a class that hold the attention or aggression of an opponent andabsorb damage so other group members can perform actions with lessdirect opposition.

Twinking—the process of buffing up a character using resources from ahigher level character, such as using a high level character to buy orotherwise obtain powerful gear for a lower level character.

The following discussion provides a brief, general description of asuitable computing environment in which the invention can beimplemented. Although not required, aspects of the invention aredescribed in the general context of computer-executable instructions,such as routines executed by a general-purpose data processing device,e.g., a server computer, wireless device or personal computer. Thoseskilled in the relevant art will appreciate that aspects of theinvention can be practiced with other communications, data processing,or computer system configurations, including: Internet appliances,hand-held devices (including personal digital assistants (PDAs)),wearable computers, all manner of cellular or mobile phones (includingVoice over IP (VoIP) phones), dumb terminals, media players, gamingdevices, multi-processor systems, microprocessor-based or programmableconsumer electronics, set-top boxes, network PCs, mini-computers,mainframe computers, and the like. Indeed, the terms “computer,”“server,” “host,” “host system,” and the like are generally usedinterchangeably herein, and refer to any of the above devices andsystems, as well as any data processor.

Aspects of the invention can be embodied in a special purpose computeror data processor that is specifically programmed, configured, orconstructed to perform one or more of the computer-executableinstructions explained in detail herein. While aspects of the invention,such as certain functions, are described as being performed exclusivelyon a single device, the invention can also be practiced in distributedenvironments where functions or modules are shared among disparateprocessing devices, which are linked through a communications network,such as a Local Area Network (LAN), Wide Area Network (WAN), or theInternet. In a distributed computing environment, program modules may belocated in both local and remote memory storage devices.

Aspects of the invention may be stored or distributed on tangiblecomputer-readable media, including magnetically or optically readablecomputer discs, hard-wired or preprogrammed chips (e.g., EEPROMsemiconductor chips), nanotechnology memory, biological memory, or otherdata storage media. Alternatively, computer implemented instructions,data structures, screen displays, and other data under aspects of theinvention may be distributed over the Internet or over other networks(including wireless networks), on a propagated signal on a propagationmedium (e.g., an electromagnetic wave(s), a sound wave, etc.) over aperiod of time, or they may be provided on any analog or digital network(packet switched, circuit switched, or other scheme).

Suitable System

Referring to FIG. 1A, a system architecture includes multiple clientcomputers or players 105 connected to one or more hosting companies 115via a network, for example via WAN/LAN/Internet 110, together referredto as a system 100. The company 115 includes a data center 120 thatincludes multiple servers 130 and one or more login servers 125 that maybe shared among any or all of the servers 130. As an alternative, eachof the servers 130 includes its own login server 125. The one or moreserver computers may host client applications, such as an MMOG, etc. Inthis example, the company 115 would be a game company hosting one ormore MMOGs, although this is only an example for ease of explanation andunderstanding. The system can be applied to any online experience, suchas a website or other online experience where users can share onlineshopping experiences and “compete” for bargains. Players may aggregatetogether because they live in the same town, like the same things, andso forth, so that they can shop together in an online environment.Players with similar or complementary desires, interests or othercharacteristics may collectively be offered products or services, oreven selected discounts, that the system identifies as beingparticularly desirable for them, as described herein. Other examples areprovided herein.

In the example of an MMOG, each of the servers may represent a separate,persistent virtual world. In some examples, a virtual world and/orinstances of a virtual world may be represented by multiple servers. Forexample, geography or map information for a virtual world may exist onone or more servers while character databases, game data structures,combat engines, etc. for the virtual world exists on one or more otherservers. In some cases, servers may represent the same virtual world(e.g., same geography, interface, etc.) but use different conventions orrule sets to govern game play and maintain separate data structures tostore information related to game interactions. For example, one or moreservers may be designated for role players to interact in one instanceof a virtual world while another server or servers are designated forplayer versus player interactions in another instance of the samevirtual word. Each server may represent a different time zone, differentgeographic region, different region or zone within a game, differentaspects of the game (such as different time periods in a historical gameor different plotlines/timelines), etc. Alternatively, while one datacenter is shown, multiple data centers, each employing one or moreservers, may be employed, with different data centers distributedgeographically. Notably, each of the separate servers may representdifferent worlds or gaming or other application environments particularto individual characteristics or desires of players to thereby provide amore compelling, targeted, or enriching environment for individualusers. Each of the servers may execute similar worlds, so that much ofthe programming involved in creating that world is identical, but insome cases certain rules or content associated with each world maydiffer. In some environments with servers sharing similar applicationcharacteristics, each server may be referred to as a “shard.” In somecases, a single server may maintain information for one or more virtualworlds, games, application environments, and/or networked activities.

In some examples, some virtual worlds may permit player versus player(PVP) play, wherein one character can kill another, while another worldmay simply be player versus environment (PVE) where characters may notkill each other. Thus, in other worlds, the same underlyingarchitectures, zones, geography, interactions, interfaces, etc. arerelatively the same, but employ different rule sets or differentconventions. In another example, each of the servers 130 may operate aseparate virtual world that includes the same or similar NPCs, monsters,terrain, etc., but one world may be for players who frequently useprofanity and harass each other verbally, another for players who wishto employ role playing, another for children under the age of 13,another for adults with at least a graduate degree, another for adultswithin a predefined geographic environment, and so forth.

Multiple servers 130 may be employed to distribute the load of multipleclient computers interacting with the data center, so that if hundredsof thousands or millions of players wish to play the gamesimultaneously, the load may be distributed among multiple servers toavoid overloading a single server. To ensure sufficient bandwidth andlatency, servers may be distributed geographically within certainregions that have multiple players, such as a server in the northeaststates region of the U.S., or even within individual cities, which canpromote interaction among players if they share other common interests,such as a similar interest in a local sports team, passion about localpolitics, and so forth.

As described herein, multiple servers may be employed to handle peakloads on the system, but, to conserve energy and resources, players maybe aggregated on certain servers while other servers are powered down orput in standby mode during non-peak times. Aspects of the invention helpforecast such events to facilitate moving players from a server to bepowered down/placed on standby to other servers that are still running.Further, by load balancing and moving players between servers, the wearand tear provided on such servers is distributed, so that the averagelifetime of such equipment is extended, further conserving resources. Asdescribed in greater detail below, the system classifies players asindividuals and/or into groups and can place each individual or group onone or more separate servers (one or more different virtual worlds orgames) to thereby provide certain players with a richer playingexperience. Furthermore, the system can track players to help ensurethat an optimal amount of server resources are provided, and to moveplayers between servers as need be, without affecting the userexperience. For example, the system classifies a first user according toone or more methods described herein and, among various usercharacteristics identified or otherwise determined during theclassifying process, determine that the user generally engages in acertain online activity, such as an MMOG, at specific times. The systemclassifies other users to identify those sharing similar and/orcomplementary characteristics with the first user and then migrates, oroffers to migrate, the first user and other users to a particular serveror user environment where these users can enjoy an improved userexperience. Exemplary benefits from this migration or grouping includehaving more users available at preferred times to share in the mutualactivity, creating a more well-rounded or mutually complementary userbase to share in the user environment or activity, optimizing orotherwise improving hardware load factors or other characteristics thatare related to user populations and playtimes, and other similaradvantages. In some cases, users might be migrated between various datacenters to balance or improve power usage based on user demographics andactivity engagement.

As also described herein, such regional preferences can be selected bythe player to enrich that player's in-game experience. Thus, a singleserver may host only several thousand players who play regularly, andthat can help develop more affinity or emotional appeal among players(such as lasting guild formations), and thereby generate a deeperexperience for the players. Players can thereby get to know severalplayers within a given region, given world, or other games more easily,and thereby generate increased emotional bonds. As described herein,aspects of the invention help players to self-select for such affinitygroups, but the system also provides an automated fashion forclassifying, matching, joining, or otherwise identifying players, forexample similar or like-minded players, within a given world or acrossvarious worlds or even among various different games or other networkedactivities. (The term “world” or “shard” can represent not only a gameor other networked activity, but more specifically, a particular set ofrules applied to a given game or activity, so that multiple games areeach similar in architecture (as noted above), but different in regardsto rules for those games and the players and characters that may playwithin that game.)

As described herein, the system tracks and sorts behavior of playersacross a network to draw correlations from or characterizations of thoseplayers and create or identify groups of similarly characterized playersor players characterized as mutually complementary. The systemidentifies, classifies, categorizes, or characterizes players andsuggests games, groups, guilds, worlds, etc. for such collections ofsimilar or like-minded players, and suggests that they join a group,undertake a quest, join a game, engage in an activity, etc. For example,based on the style of play of a player and that player's indicatedpreferences, the system may recommend a guild associated with similarplayers or a world that suits the player's preferences. As anotherexample, the system may recommend other games to a player based onsimilarities between that player and other players playing that game orwho have played that game. For example, if the system determines that aplayer's play style with respect to a particular type of characterclosely matches or otherwise positively correlates with that of anotherplayer or set of players who have begun playing another game, the systemmay recommend the other game to the player. Thus, in some embodiments,the system identifies a first player associated with one or morecharacteristics and a first networked activity and at least a secondplayer associated with one or more characteristics and a secondnetworked activity. Based at least in part on a correlation between oneor more of the first player characteristics and one or more of thesecond characteristics, the system recommends the second networkedactivity to the first player. The correlation between the first playerand the second player may be a positive correlation and/or a negativecorrelation between one or more characteristics. In the role-play gamingenvironment, guilds or groups may be established to better build a senseof community among its players, and the servers 130 may be selected orsegregated to execute games only for certain guilds. Each player'savatar may have a visual indication of the guild or group to which thatcharacter belongs. Alternatively or additionally, the system alsoclassifies users to identify those users that are dissimilar oruncomplementary. For example, the system may determine, based on userfeedback and/or via autonomous methods described herein, that a firsttype of player having one or more characteristics generally does notenjoy engaging in a networked activity with or otherwise interactingwith a second type of player having one or more characteristics. Thus,if the system determines that a first player has one or morecharacteristics that exceed or are below a certain threshold, the systemmay, based on this determination, identify or group other users asuncomplementary or otherwise undesirable for engaging in one or moreactivities with the first player based on the characteristics of thoseother users. The system may migrate the first player to servers or gamesaway from the other users, suggest different activities for the varioususers that minimize the likelihood of them interacting, hinder usersfrom interacting for example via restrictive chat filters, or performother actions to improve the user experience.

Suitable Client Devices

Referring to FIG. 1B, an example of multiple client computer devicesthat may communicate with the data center 120 are shown. In particular,a generic client device 140 (described herein) is coupled to the datacenter 120 through a network, such as a TCP/IP network 110. The clientdevice may be a mobile device or cell phone 141, smart phone 142, laptop143, tablet, etc., all of which communicate with the network 110. Forexample, the cell phone 141 communicates with a WAN 150 (such as acellular telephone network), via a cellular antenna 152. The smart phone142 and/or laptop 143 may communicate wirelessly with a LAN 154 via anaccess port 156. Other mobile devices may also be employed, such astablets, personal digital assistants, wearable computers, implantedcomputers, vehicle-based computers, and so forth.

The generic client device 140 can include multiple components, includinga display device 160, one or more processors 162, and one or more typesof memory 164. A text input device 166 can be a keyboard, keypad,joystick, microphone, etc., while an audio output device 170 can be aspeaker, headset, earphones, audio output module, and so forth. Otherinput devices can be motion sensors such as accelerometers or compasses,or location-based sensors, such as those that use GPS. Further, inputdevices can be a video capture device, such as the KINECT by Microsoft,which can be used to generate video for video chat, be used to abstracta player to generate a motion-based avatar or animation, sense movementof the player for motion-based games, and so forth. The system may alsouse information or metrics associated with a user's physical performanceor capabilities, for example information captured by a video capturedevice or via biometric feedback sensors, to match players based onphysical characteristics such as their level of fitness or physicalactivity while interacting with a game. For example, physically activeand/or coordinated players may have a preference for playing withplayers who exhibit a similar degree of physical activity and/orcoordination as opposed to players who do not move or lack coordinationand vice versa. Similarly, the system may incorporate the physicalmovement captured by motion sensors, such as Nintendo Wii controllers,as a basis for matching players. For example, players who tend toincorporate a lot of motion into their playing style may prefer to playwith players having a similar play style and avoid players who play withvery little motion. Furthermore, players may want to be matched withplayers based on a combination of a motion preference and the type ofgame being played. For example, a player playing an action or sportsgame may wish to play with players who move a lot while players playinga strategy game that does not encourage movement may wish to play withplayers who exhibit less motion. The generic client device 140 can alsoinclude a haptic output device 172 that provides vibration ormotion-based output to a user, while an audio input device 174 can be amicrophone or other audio input device. Other output devices 176 orinput devices 178 are also possible.

For example, a location determining input device, such as a GPS radio,can help track players in a game requiring mobility among players, suchas a geocaching game. Other games may require players to move throughouta town to perform a treasure hunt, solve puzzles, gatheritems/information, etc. In another example, the generic client device140 can include a biometric input device 180, such as a heart ratemonitor, blood pressure monitor, blood oxygen level monitor, EEG, EKG,or any other biometric sensor. Such biometric input may be employed inan athletic-type game, such as one where players compete in an athleticevent using wearable devices or compete to lose weight over apredetermined period of time. Another example may be a medical-basedgame or training aid to determine a diagnosis among multiple health careprofessionals or amateurs. The system may also use GPS data to matchplayers based on their location, thereby allowing players to meet peoplein their general vicinity (e.g., neighborhood, zip code, city, state).The system may also use the GPS data for exclusionary purposes (e.g., toprevent a player from interacting online with people in certain areas,such as people in the same neighborhood or city).

Other input devices may include sensors to measure environmentalconditions, such as pressure, temperature, altitude, etc. In oneexample, the players may be underwater, using waterproof mobilecomputing devices, and playing a game with scuba equipment, whereplayers perform similar activities (e.g. searching for items/animals andtaking pictures of found items), but depth, direction, temperature orother environmental conditions affect gameplay. Another example may be agame involving amateur pilots who need to fly a predetermined route thatincludes altitude, speed, and other variables, and the game serverprovides instructions and feedback, and provides status reports/updatesto fellow, competing pilots playing the game.

Suitable Character Display

Referring to FIG. 2, an example of a screen display 200 for displayinginformation regarding character equipment and statistics is shown. Inthis example, the screen includes two sections, an equipment section 210and a statistics section 215. Each player can have one or morecharacters, with each character represented by an avatar 205, which isbasically a virtual representation of the character that the player usesor controls within a given game or virtual world. Most avatars in gamesare generally humanoid, but it could also be an animal, a single-celledorganism, a robot, and so forth.

The avatar generally has equipment that it can use. In the example of ahumanoid avatar 205, section 210 displays equipment that the avatar mayemploy on portions of that avatar's body, such as head (for a helmet,hat, wig, etc.), ears (for earrings, headphones, etc.), neck (fornecklace, tie, etc.), back and chest (for armor, clothing, etc.),shoulder (for shoulder pads, armor, epaulets, etc.), wrists (forbracelets, watches, etc.), fingers (for rings, nails, tattoos, etc.),legs (for armor, clothing, etc.), and feet (for shoes, boots, etc.). Forexample, a character's avatar may have finely-crafted and studdedleather armor covering its chest, back and shoulders that booststatistics (armor class, intelligence, resistances, etc.) for thatcharacter. Much of the equipment relates to augmentation of thecharacter to provide enhanced statistics, abilities, or aesthetics forthat character. As described herein, much of the equipment may have apoint value or weighting associated with it that can help match playersto a given game, a given quest, a given guild, etc.

Other equipment may include a main weapon, an off-hand weapon or shield,a ranged weapon, or other items that the user may carry, hold, or use,such as portions, scrolls, climbing equipment, lock picking equipment,trap enabling/disarming equipment, surveillance equipment, computeraccess equipment, keys or security equipment, and so forth. Equipment isoften dictated by the game in which the character plays and mostequipment is unique to that given game. However, some games may permituse of equipment obtained in other games as described herein. For gamebalance reasons, some equipment may only be wearable or usable bycertain classes. Therefore, a warrior may, for example, use any type ofarmor, whereas a wizard or DPS character may not be able to use mosttypes of armor. In some examples, the system may allow a character inone game to send or “mail” items to characters in another game. Forexample, a character in a fantasy-themed game may mail or otherwisetransfer an item, such as a sword or portion to a character in aspace-themed gamed. Other similar examples of item transfers and/ortransformations among differing games and genres are contemplated.

In some embodiments, the system may “transform” the mailed item to makeit compatible with the space-themed game. For example, a sword may betransformed into a raygun. As another example, chain mail armor may betransformed into a spacesuit. In some embodiments, the system provides apreview of or choices to the user regarding how the item in a first gamemay be changed or otherwise transformed into different items in one ormore other games. Users are presented with various options to modifyattributes or characteristics of the item in different games or evenselect among one or more different items to transform the item into inthe different games. In some embodiments, the user is presented with anoption to transform an item in the same game, for example when movingfrom one server or virtual world instance to another in the same game,taking into account differences between virtual world instances of eachserver such as server age, economic state, average experience levels,character diversity, etc. A user selects a first item to transfer from afirst game to one or more second games. Based on one or more attributesof the first item, the system determines one or more different items inone or more second games that the first item can be transformed into.Databases or other data structures correlating items, attributes, and/orcharacteristics between games may be consulted to facilitate thisdetermination. Based on the determination, the player is offered achoice to transform and/or transfer the item into one or more items inone or more games. In some embodiments, the player is allowed to keepthe item in the first game and also receives the correspondingtransformed item(s) in the one or more second games. The system thentransforms the item or otherwise makes available the other item(s) inthe one or more second games. For example, a user wishing to transform asword in a fantasy-themed game may be offered the option to transformthe sword into a pistol with certain attributes or a rifle with certainother (or similar) attributes in a western-themed game or a club withcertain attributes or one or more different swords with certainattributes in a different fantasy-themed game. Similar relationships andtransformations may also be tracked and offered with respect to playercharacters, avatars, etc. Thus, in general, the system includes a way oftransferring digital objects and/or characters between electronic gamesor virtual worlds. This includes receiving at least one data object thatdefines a first digital object, where the data object defines statisticsor values for use of the digital object in an electronic game, virtualworld, or other online endeavor. The system normalizes or otherwiseadjusts the statistics or values of the digital object, and thenconverts the normalized statistics/values into new statistics/values foranother data object. The other digital data defines another digitalobject to be used in another electronic game, virtual world, or anotheronline endeavor.

For example, one medieval-themed game may use a range of values between0 and 10 to represent armor (or other defensive statistic), whileanother game (such as a space-themed game) may use a range of valuesbetween 100 and 1000, and thus the system may perform a simple scalingcalculation to convert both ranges into a normalized value, e.g. a rangeof 0-100. (Alternatively, the system skips the normalizing and simplyemploys a calculation to convert a statistic of one game to that for usein another, without the intermediate step of normalizing.) The systemmay make other changes. For example, the original digital object caninclude an image file for the digital object (e.g. a sword), and theconversion substitutes that image for display to the user with anotherimage file (e.g. an image of a ray gun), where both images are stored inone or more databases.

To assist in performing the transformation, lists of items associatedwith a plurality of different games may be stored in databases or otherdata structures. The system may use a mapping table or other means tocreate corresponding relationships between items of different games.Attributes, characteristics, and other aspects of items are tracked andrelated and/or adjusted among various games and activities. Thus, forexample, a magic sword in a fantasy-themed game might be mapped to orotherwise associated with a laser sword or laser rifle in a space-themedgame and each may also be mapped to or otherwise associated with apistol in a western-themed game. In some cases, the system may provide alist of options for transforming a character and/or an item. Forexample, when transforming a quiver of arrows the system may prompt aplayer to select from a magazine of bullets, a hand grenade, etc. Inthis way, the player may prefer or appreciate the options and becomemore invested in the game. Similarly, character attributes, specialabilities, classes, and other game-specific characteristics may also berelated and mapped between different games permitting not just items tobe transferred or mailed between games, but also entire characters alongwith some or all of their items, attributes, and abilities, sometimestransformed as appropriate, as further described herein. Thus, forexample, a level 12 orc mage in a fantasy-themed game may be transformedinto a level 17 human scientist in a modern-day military-themed game ora level 9 Jovian chancellor in a futuristic space-themed game. Thispermits a publisher, for example, to offer players in a first game theopportunity to come try out or join a second game using charactersand/or items generally corresponding to a level of achievement and powerachieved in the first game without necessarily having to start fromscratch or at the beginning or a lower level in the second game. Such anopportunity can be offered on a time-limited basis: for example, aplayer can enjoy playing the new game for a week or a month for free,but afterwards need to purchase the game, and may need to start at thefirst level or at the beginning of the game. Furthermore, itemsassociated with the character may be transformed accordingly.

In general, each item is a digital object defined by a globally uniqueID (GUID) or other identifier. A game server will typically store adatabase of such objects, their IDs, their statistics, an image of theobject, etc. The digital object is associated with the character as longas the character possesses that object. Much of the equipment affectsthe statistics shown in the statistics section 215. Thus, if thecharacter employs chain mail armor, he may have a better armor classrating than a character that employs only leather armor. An example ofsuch a digital object data structure or database is shown in Table 1below:

TABLE 1 Digital Object Data Structure GUID Item Name Points AbilitiesRestrictions Owner Image 345721 Flaming 60 +10 to Min. 60 [GUID forplayer profile [URL to Sword hit +20 Strength and character owning item]image fire File] damage 367721 Ring of 50 30% acid none [GUID for playerprofile [URL to Acid resistance and character owning item] imageResistance File] 145721 Hat of 100 +20 to Min. 80 [GUID for playerprofile [URL to Memory Intellect Intellect and character owning item]image File] 67883 Stealth 120 +10 to Min. 40 [GUID for player profile[URL to Armor Armor Coordination and character owning item] image Class+30% File] to Hiding Ability . . . . . . . . . . . . . . . . . . . . .

In the above example, the points are used for equipments weightings, asdiscussed herein. The restrictions are minimum requirements for use bycharacters. The database tracks the current owner and links to the datastructure defining a player and his character(s), as discussed herein.The database may include image files that represent the displayableimage of the item. Further details regarding equipment weighting isprovided below. The system may also include an “ownership table” thatmaintains associations between characters and items (e.g., a piece ofequipment, portion, book, etc.) that each character currently owns. The“ownership table” may store, for each character, the GUID associatedwith each item that the character owns along with an indication of thecurrent state of the item (e.g., condition, upgrades applied to theitem, damage taken, etc.), the current location of the item (e.g.,equipped by the character, in a storage location associated with thecharacter, etc.), etc.

While the avatar 205 is shown as generally humanoid, as noted above,other avatars may be employed. For example, the player may employ orhave a pet or mount, such as a winged horse, that may have associatedequipment. The equipment held by another form of avatar may have adifferent set of parts that can be equipped (e.g., a winged horse has nofingers but may be able to wear separate pieces of equipment on its hindand fore legs). If the avatar is a single-celled organism, equipment mayrepresent genes or DNA strands that the single celled organism canemploy to obtain certain abilities. Many other variations are, ofcourse, possible within a given game.

The statistics section includes a general statistics portion 220 thatincludes the character's name, class, race, level, armor class (AC), hitpoints (HP), mana and power. Armor class indicates how difficult it isfor the character to be injured in physical attacks. Hit pointsrepresent the number of life points for the character before he or shedies or is “knocked out.” Level indicates a general level of experienceor effectiveness of the character within a game. Mana can representpoints used to cast spells while power may represent points used toperform certain abilities. The statistics mentioned above are providedby way of example, and other statistics are contemplated.

The class, race, level and/or other general statistics may affect howthe system automatically suggests games, worlds, quests, etc., for aplayer. For example, if a game includes a tanking class and a healingclass, the system may determine that a high DPS class would be needed tohelp round out or balance the group. This determination may be based on,for example, the success rate and makeup of other groups in similar gameinteractions, information provided directly by players or the gameitself, etc. Thus, the system may identify characters having a high DPSwith a similar level, and possibly other similar characteristics orstatistics, to join with the group. The identification may be based onthe system's analysis of game interactions and/or information providedby a player. Another class may be a crowd control class, such as a typeof wizard that can cast spells affecting large numbers of monsters.

For example, the system may statistically determine how quicklydifferent users or groups achieve a particular goal or accomplish atask, for example how quickly they progress through a given level orarea of an electronic game, and analyze the members of that group orcharacteristics of the users. The system can then determine that thegroups or users that are able to more quickly progress through a givenlevel or area all have a particular set of characters with particularclasses/races/levels/guilds/other statistics, and thus the system canthereby determine a “optimal” group or user makeup. This group or usercomposition could also be pre-determined and the system trained toidentify users and groups satisfying various criteria corresponding todesirable groupings and classifications. In either case, user actions,interactions, behaviors, items, characteristics, and other informationas described herein are tracked and recorded in one or more databases orother data structures. This information is analyzed to determineinformation items that satisfy certain criteria and users are classifiedand/or grouped accordingly. Thus, the system can help players optimizetheir group by identifying which characterclasses/races/levels/guilds/other statistics are missing from the groupand identify other players who may be a good match for joining thatgroup. Alternatively or additionally, the system may employ languageprocessing algorithms to analyze communications among players, withinwebsites, blog postings or comment/chat boards for the game and so forthto identify preferred group makeup from analyzed postings, comments,etc.

As another example, in monitoring game interactions, the system maytrack the characteristics and behaviors of various groups with respectto a particular quest or activity (e.g., how often groups successfullycomplete the quest, how long it takes successful groups to complete thequest, the attributes of the characters in each group, how manyexperience points each character in the group earns while completing thequest, etc.). If groups that include certain characteristics, forexample one healer, one tank, and one DPS are five times as likely tosucceed in completing the quest than other combinations, the system maytry to match characters in order to create a group consisting of onehealer, one tank, and one DPS. As another example, if a player requeststo play with a tank, the system may attempt to match that player with atank. Furthermore, if DPS characters tend to increase experience pointsat a relatively high rate for a particular quest as compared to otherquests, the system may be more likely to recommend the quest to a playerwho is looking to increase the experience points of a DPS character.Characters, or classes of characters, can have specializations. Forexample, wizards may have specialization in destruction spells, illusionmagic, crowd control magic, etc. As another example, a warrior mayspecialize in a certain type of weapon (e.g., melee weapons, rangedweapons, etc.) and be matched to other characters or players based onthat specialization. Other examples are of course contemplated.

The attributes statistics section 225 includes various attributes forthe character, such as the character's strength (which can indicate howeasily the character can inflict melee damage and is typically importantfor a warrior and how much damage a character takes when attacked),intellect (which is typically important for a wizard and can help witheffectiveness of spells), soul (which can be important for healers),coordination (which can be important for certain abilities, such asthose requiring small-motor abilities like picking a lock or alarge-motor abilities, such as shooting a bow), physical (which canindicate how many additional hit points the character may have), andcharm (which can indicate the diplomacy or skillfulness the characterhas in diplomacy, haggling when buying or selling goods, how likelymonsters will attack that character, how likely the character is toobtain a monster as a pet, and so forth).

Equipment in the equipment section 210 can affect statistics in thestatistics section 215. For example, the character may include abracelet on his wrist that adds points to his strength. Other statisticsportion 230 may include statistics relevant to melee combat, such as apercentage to hit, percentage to do critical damage, damage done persecond (DPS), as well as ranged-attack effectiveness (not shown). Otherstatistics portion 230 may also include statistics relevant to castingspells, such as spell damage related to a percentage to hit monsters,and DPS effectiveness. A resistance portion indicates the character'sresistance to certain types of attacks, such as attacks from fire, cold,spell, poison and disease attacks, where each resistance may berepresented as a percentage. Of course, resistance to other forms ofattack is also possible. Further, equipment may increase or decreasesuch resistance, such as a ring or body armor to increase thecharacter's resistance to fire-based attacks.

While not shown, statistics section 215 may also include an indicationof a character's traits or skills. These traits or skills can representactivities important to the game, such as running, jumping, eluding,hiding, and other gross-motor skills, as well as fine-motor skills, suchas picking locks, disarming or enabling traps, forging documents, etc.While these skills may be based on strength and coordination attributes,other skills may be based on other attributes, such as intellect.Intellect-based skills may include, for example, the ability tounderstand other languages, specialized knowledge of informationimportant to the game (e.g., history, customs, architecture, survivalskills, etc.).

Together, the screen 200 represents the composite features,characteristics, behavior, and statistics of the character that affecthow the character interacts with a world, and how effective thecharacter is in performing particular actions. As the character gainsmore experience, many of the statistics can increase, new abilities canbe obtained, and the character can increase its overall effectiveness inachieving goals within the game. Certain games may require one or moreparticular abilities or minimum general statistics, attribute statisticsand/or other statistics to play in a game. The system may automaticallyanalyze a database of all such characters to help identify charactersthat may be particularly effective in a world, game, quest, etc. beingcreated. For example, a game may include a particular quest thatrequires diplomacy, where a goal of the quest is to influence NPCs inthe game. In this example, the system may automatically identifycharacters that have high charm attributes and who may thus be moreeffective in influencing NPCs. The statistics discussed above areprovided by way of example; other statistics are contemplated.

Suitable Game Environment

Referring to FIG. 3, an example of a display screen illustrating aMMORPG user interface 300 showing a virtual world that includes a groupsection 305 depicting basic statistics of the player 310 and other groupmembers 315 with whom the player is interacting. To interact with thevirtual world, each player at each client device 140 inputs movement,combat and other actions via various input devices, such as keyboards,game controllers, microphones, or other input devices such as motionsensors, video cameras for capturing live action, as noted herein.

The group of characters associated with the group members shown as agroup 325 with the character 330 corresponding to the player 310. (Whilethe on-screen representation of a player's character is an avatar, forsimplicity of discussion, the term character will refer to both the oneor more data structures defining the attributes, statistics, andpossessions of the character in a game and the on-screen displayedavatar.) As shown, the selected statistics include hit points, power,and mana but may include any other statistics noted herein. The groupsection 305 helps indicate how each of the players' characters arefaring in the game. For example, if the group is fighting a monster 335,all players in the group can see who is losing hit points, who is faringbetter than others, and allow the group to communicate and determinestrategy. While a group of players is shown, the player may be involvedin a solo activity, and thus no group would be involved.

The game milieu 338 includes a two or three dimensional depiction ofcharacters in the group 325 (including player's character 330), amonster 335, and as shown, a castle 340 and forest 345. Of course, anyform of graphic may be provided for the game. The game may be depictedfrom a number of different perspectives, such as first person, thirdperson, top-down, etc. In some examples, the depiction of the game maychange perspectives for various purposes. For example, while a characteror group of characters explore a map, the game may be represented in atop-down manner. However, when the character or group of charactersengage in battle, the perspective may change to first person. Further,rather than being automatic, in some embodiments, the player may selectthe perspective. The milieu 338 represents the virtual world in whichplayers interact. The monster 335 may be represented as an offensivetarget 350, with associated statistics, followed by a defensive target355, who may be one of the characters currently engaging the monster inbattle. The indicators 350 and 355 help show a near real time damageinflicted on the monster or character.

A portion of the screen 330 may indicate with icons, text or otherdisplayable information, buffs or effects 360 that may affect the group325. For example, an armor buff can increase the armor class of thegroup to make it more difficult for the monster to hit or cause damageto members of that group. Another example of a buff or effect can be aspell that permits enhanced damage to the monster based on attacks fromthe group.

A compass or location indicator portion 365 shows a current position ofthe group within the world, and a location indicator 367 may provideprecise coordinates for the group 325, or player 330. The locationcoordinates can be x, y and z axis coordinates, polar coordinates,spherical coordinates, and so forth. As described herein, the system maytrack the location of each player during gameplay and analyze locationdata to help determine how a player plays a given game and may, forexample, further determine which other players that player may wish toplay with. For example, some players may have a tendency to explore anarea in detail for hidden items, monsters or characters with which tofight, or paths to yet undiscovered areas and wish to play with playershaving similar tendencies. As another example, some players may wish toplay with players who navigate directly from boss monster to bossmonster or town to town without exploring other areas.

A menu bar 370 provides access to various displays of information (notshown). For example, an abilities screen can display abilities that thecharacter currently has and those that the character can gain over time.Some abilities may be listed in the menu bar 370 so that by clicking ona displayed ability, a particular action is performed, such as climbinga tree, influencing a merchant, casting a spell, healing a party member,performing an attack, and so forth. Another item or tab in section 370may allow the user to access an inventory to show equipment, itemscollected, journal pages, and other things within the character'spossession.

An affiliation or guild tab may show or provide access to informationregarding the character's guild, such as a roster of guild members,guild members who are online, guild members who are offline, the levelfor each of the characters in the guild, any affiliations of characterswithin the guild, where each guild member may be within the world, thecurrent activities of the guild members, etc. Another tab in section 370allows the player to access spells currently in possession of, ormemorized by, the player's character. In some games, the player may makecertain spells readily available to the character such that clicking onthem within section 370 causes those spells to be cast. The guild tabmay allow the player to access a group of fellow players that the systemhas assembled according the methods describe herein.

Section 370 may have tabs for other information, such as generalmaintenance information to allow the player to adjust the interface,video display, sound settings, chat settings, languages. Further,section 370 or other means allows the user to access the screen 200 ofFIG. 2, and to access other screens described herein, such as those thatallow the player to select or adjust personalization settings to helpconvey to the system how that player typically likes to play (e.g. withor without fellow players from the same town, fellow players with thesame socioeconomic or educational background, etc.). For example, aplayer may wish to avoid playing with people in the same town to avoidmixing their real life persona with their online or game persona, etc.Alternatively or additionally, the system may exclude or filter forcertain identifiers, e.g., network identifiers, domains, IP addresses,IP ranges, mail servers, social network handles, or other affiliationsto allow the player to avoid playing with colleagues from work orcertain social circles, or help permit the player to interact with workcolleagues or individuals on a publicly available listserv, bulletinboard, friends network, or other publicly available electronic list ofindividuals and associated electronic addresses.

A commands section 375 allows the player to enter a command or series ofcommands, such as a series or queue of spells to case. The commandsection may even include a small program or macro for executing multiplecommands simultaneously or sequentially. A chat section 380 allowsplayers to communicate via instant messaging, chat, other textual-basedcommunication, voice over IP, other audio-based communication, videochat, other video-based communication, and so on. For example, if theplayer is interacting with a deaf player, the system may employspeech-to-text to provide “closed captioning” for the game. The chatsection 380 may also report or display an interface of combat statisticsor other information in the gameplay, such as an amount of gold thegroup obtains, experience points gained after defeating a monster, etc.Such status information can be displayed within the chat section 380.Furthermore, section 370 may have a tab to allow the player to filterwhat information is displayed within the chat section 380. For example,a filter could remove profanity, racist slurs, and other objectionablelanguage selected from a blacklist of such words, so as to allowotherwise compatible players to communicate without allowingobjectionable language or content to be exchanged between the players.

A quest section 385 lists tasks, objectives or quests that the playersare attempting to achieve or perform within a game. For example, onequest may be to find five items, where three of five have already beenlocated. Another may be to find a particular artifact, where currentlythat artifact has not been found. Another may be to find an NPC namedRob. Another may be to kill five specific creatures or types ofcreatures. In the displayed game, if the group 325 defeats the monster335, it may gain another one of the items, and therefore the objectivessection 385 may show that four of five items have been located.

Section 370 may include a quests tab that lists quests or objectivesthat have been completed, as well as details on how and where eachelement of that quest was achieved. Section 370 may also include a tablisting a number of available or selected quests, as well as who in thegroup is on the same quest, where the game permits individual players topursue different quests as opposed to quests that are to be pursued in agroup, etc.

In the example below, the system analyzes the quest or objectives that aplayer or group accepts, how quickly the player or group completes theseobjectives, which objectives the player or group chooses not to pursue,and so forth. For example, the system may identify players that acceptor complete the same quests or types of quests. As another example, thesystem may match players who tend to complete similar quests in similaramounts of time as this may provide an indication of each player's skilllevel and/or play style. This information allows the system to furthermatch players together for a more enjoyable or enriching experience andavoid matching players in a manner that may create a less enjoyableexperience for any players involved. For example, a player who tends tobe an explorer may want to avoid playing with a player whose only goalis to minimize the amount of time required to complete quests or defeata particular monster. As another example, players who prefer to partakein combat with players who engage in a predetermined sequence or“rotation” of actions (e.g., attacking and casting spells in aparticular order) to defeat a monster or complete a task may want toplay with similar or like-minded players as opposed to players whoimprovise during battle or experiment with different techniques andtactics.

Suitable Game Map

Referring to FIG. 4, a screen display 400 shows a map of the virtualworld in which the player 330 and group 325 move and interact withdigital objects (movable or immovable) within the virtual world. Forexample, screen display 400 may show the group of characters as thecharacters navigate through a forest and encounter various entities,such as monsters for battle, other characters for information about thearea, merchants for trade, etc. As described herein, each depictedelement within the virtual world is represented by a data structure ordata structures indicating, for example, its location within the world,whether it is movable or immovable, if it is a monster, its relevantstatistics such as its armor class, hit points, damage per attack, etc.,and an image file for visually depicting the digital object.

The digital world may be represented by a map, a portion of which isshown in screen 400, which is divided into standard Cartesiancoordinates and quadrants separated by axes 425, with a quadrant 405representing negative x values and positive y values, a quadrant 410representing positive x and y values, a quadrant 415 representingpositive x and negative y values, and a quadrant 420 representingnegative x and y values. Z-coordinate values may represent a distanceabove (positive) or below (negative) sea level. As shown in FIG. 4, theplayer's character 330 is at coordinates (875, 778, 210) all positivevalues indicating that he is in the second quadrant 410 at a positionabove sea level. Each of the digital objects is similarly represented bycoordinates within the coordinate system. So, a road 430, forest 435,lake 440 and mountain 445 all have coordinates defining their locationwithin the virtual world. As noted below, it is important for the systemto understand the location of certain locations within the virtualworld, such as public locations (taverns, town squares, etc.), craftshops (blacksmiths, forges, mills, etc.) and so on.

The system tracks movement and interactions of all players within thevirtual world over time to understand how that player likes to play, whothat player often interacts with, where, and for how long, what actionsthe player takes, places the player visits, NPCs spoken to, etc. The mapalso shows the castle 340, party 325, forest 345 of FIG. 3. Bymonitoring the player within the virtual world, the system can determinetypical gameplay for that player, map areas of the virtual world toparticular activities performed by the player in that area, etc. Forexample, if the player has his character often go to the trade shop andspend many minutes, game cycles or even hours in the trade shop, thesystem can determine that he is likely fashioning items, such as arrows,to gain experience, equipment, gold or other game-related statistics. Insome examples, activities performed by a player may be discerned byanalyzing information other than character interactions. For example, agame publisher, or entity with access to game data, may be able tomonitor a character's inventory directly via data structures maintainedby the publisher and determine that the player is having his characterperform particular actions based on changes to the character'sinventory, such as mixing portions, repairing armor, fashioning weapons,frequent upgrades in items, etc.

The system can analyze character movement and generate metricstherefrom, either calculated locally on the client, generated at theserver, or both. In general, and as described herein, the system cananalyze user behavior or movement within electronic games, virtualworlds or other online endeavors by first receiving data representinglocations within the game/world/endeavor, and time data representing howlong the user spends in those locations. This data may be based on agrid, Cartesian coordinate system, or other location determinationsystem. The system calculates at least one statistic or metric of theuser's movement within the game/world/endeavor and determines acharacteristic of the user by comparing the calculated statistic/valueto a predetermined threshold or parameter. The system can then associatethat determined characteristic with the user and store it in a databasefor later use, such as for player classification and/or matching.

The threshold can represent a statistically determined dividing linebetween an average among all players, and those players within apredefined category or characterization of players who are statisticallymore likely than the rest of the players to perform certain actions.Thus, in some embodiments as described herein, the system gathers datafrom all players to calculate an average time period or other values forall players for computing some of the various metrics described herein.For example, as described herein, a player characterized as an“explorer” will, on average, traverse more zones of a virtual world, andspend less time in each zone, than the remaining players in that game.In another example, a player who is characterized as a “role player”will spend more time emoting, communicating (with flowery language), andoften less time moving about a virtual world, then other players. Inother words, the thresholds can represent deviations from the norm forcertain behaviors that are performed more often than not for certaincategories of players.

For example, the system can divide the virtual world into zones andtrack movement between zones, or analyze more finely for movement withinindividual areas of a zone, such as dividing the world into smaller gridlocations by overlaying a virtual grid onto the virtual world. One zonemay represent a town, in which case, the system may wish to analyzemovement data within the town more closely than if the player were in aprairie zone that lacked multiple discrete virtual objects within thatzone.

The system may analyze other data, e.g. activity data, with the locationdata to help further gather important behavioral data regarding theuser. For example, if gathered information indicates that the user isinvolved in a battle, then more accurate data regarding movement of thatcharacter in battle can provide important insights into that player'sbehavior. In one example, a more skilled player may frequently moveabout an opponent to identify areas of weakness, whereas a less skilledopponent may simply stand and fight.

Further, the system can coordinate location information with chat datato help further confirm the type of gameplay in which the player isengaged. Thus, the system may determine that the player is a “crafter”and that he is often performing crafts within a game to help builditems, develop skills, obtain game points, etc. Alternatively, a playermay be stationary in a given location, but be performing lots ofcommunicating or emoting or chat with other players, which can indicatethat the player is in a tavern or town, and that the player often likesto interact with various other players. Further, the system candetermine whether the player is interacting with several players withina group, or players outside of that group, but are also involved in thegame. Roleplayers, for example, may be determined by identifying acertain number of players interacting within a certain geographicproximity for a time period exceeding a particular threshold. The playerinteractions are analyzed to determine chat and emote levels exceeding athreshold. Additional language analysis may be performed to identifyspeech patterns characteristic of role-playing such as “in-character”language, archaic grammatical or vocabulary constructions, lack ofcontemporary speech patterns for a particular period of time, etc. Basedon this analysis and identification, certain players satisfying thesecriteria and exceeding the various thresholds specified may beidentified as role players. In addition, by tracking this informationover time, the system can identify areas where players (previouslyidentified as role-players or not) habitually engage in theseactivities. Thus, the system may first identify one or more role playersbased on their actions in a particular place. Over time, by continuingto track these players, the system may identify other locations wherethese players engage in similar activities. Players they engage with mayalso more easily be identified as role players. For example, the systemidentifies a first player as a role player (or other player type) andidentifies a second player whose interaction with the first playersatisfies one or more criteria or exceeds (or is less than) one or moregiven thresholds. The system weights or otherwise increases thelikelihood in its calculations that the second player is also a roleplayer (or other player type). In some embodiments, the second playerhas not been previously identified as a role player (or other playertype) and in others the second player has been previously identified asa role player (or other player type) and the system increases aconfidence metric or factor that the second player is a role player (orother player type) based at least in part on the interaction with thefirst player. In addition, by identifying and monitoring locations wherepreviously identified role players (or other player types) interact, thesystem can track interactions at these locations of other players notpreviously classified as role players (or other player types) to moreaccurately identify them as such. Other types of players and gameactivity such as crafters, crafting, duelers, dueling, etc. may also besimilarly tracked and identified.

As yet another example, the system can analyze the player's movementwithin the virtual world during a given session, and determine whetherthe player has often engaged in combat, communication, crafting, etc. Ifa player moves frequently about the virtual world, between multiplezones, without engaging much in combat, and stays only a few minutes inany given location, then the system can determine that the player is an“explorer”, and characterize the player as such. The system may alsodetermine that the player uses a character to perform repetitive actionsand increases a particular attribute or characteristic of the character,often at a higher rate than average players in the game, then the systemmay characterize the player as a “grinder”. Furthermore, the system maytrack the movement of virtual items within the game and generate anindex of use and possession of that item, to thereby build a history forvirtual items, which may be useful in analyzing player behavior andvalue of digital items. Thus, the system can generate multiple metricsbased on player movement and thresholds to more accurately determineplayer behavior, as described herein.

Suitable Communication Protocol

Referring to FIG. 5A, an example of a data transmission unit, such as adata frame or packet 500 includes a transport header 505, a data payload510 and a footer or trailer portion 515. An example of a suitabletransmission protocol for transmitting the packet may be the well-knownTCP/IP protocol. The header portion 505 may include identifyinginformation regarding the client device, such as a client ID, cookie ID,originating IP address, MAC address, and other information identifyingthe client device. The header may also include game information such asa game ID, game version, virtual world identifier, etc., and/or playeridentifying information, such as a player ID, user name, logincredentials, and other information. The game ID, game version, etc,helps identify for the data center to which server to route the packet,and game on that server if a server is running more than one game. Ifthere are multiple versions of a game, then the header portion 505 mayinclude a game version identifier. Typically, the header may be smallcompared to the payload portion 510. The header may also includesecurity information, a game identifier, a virtual world identifier, aswell as standard information TCP/IP packet, such as a destinationaddress, a packet number, and so forth.

The data payload portion 510 includes most of the game data, such ascoordinate locations in which the character is located, what items thecharacter currently possesses or is equipped with, what actions thecharacter took in the game, actions that the player would like thecharacter to take, a direction of movement for the character, a rate ofmovement for the character, keystrokes by the player (such as fortext-based communication), a player or character ID to identify theplayer to whom text messages are to be sent, an indication of a player'sselection of characters or objects within the game, an indication of amacro to be performed, and so forth. Payload data may also includecombat information, commands, interface updates, character efficiencydata, timing information, an indication of sequences performed by auser, basic game play data, information reflecting changes to the stateor appearance of an avatar, etc. In some examples, different datapayload portions may represent different types of data. The packet 500may end with a footer portion 515 that may include errordetection/correction codes (e.g. CRC codes), other message identifier orintegrity values, end of message/end of packet flag, etc.

Referring to FIG. 5B, each of the client devices 140 transmits multiplepackets 500 to a game server 530 via the network 110. The game server530 in turn sends packets back to the client device 140 via the network110. In this way information is exchanged between clients and the serverduring gameplay. The game server may receive each packet and analyze thepackets to determine a player's preferences, communication styles,character preferences, play characteristics, and so forth. The servercan analyze packets to determine not only the player's preferences andperformance within a game via the player's interactions with the game,but also the player's preferences and performance when interacting withother players. Alternatively, or additionally, the system may determinea player's preferences and performance by analyzing game-relatedinformation captured from, for example, RAM, video RAM, informationexposed through an API provided by a game, interprocess communications,data structures maintained by the game, function calls to the game orassociated software, etc.

System Details

In some embodiments, the system collects data related to gameinteractions, aggregates the data, and analyzes the data to identifycharacteristics of players and/or characters and develop a profile forplayers and/or characters. The system may collect the data from any of anumber of sources and in any number of ways, such as by capturing datapackets, accessing game data stored in random access memory (“RAM”) oron disk, accessing and processing image data stored in video RAM,retrieving information exposed through an API provided by a game orother source, intercepting interprocess communications, accessing datastructures maintained by the game, executing function calls to the gameor associated software, and so on. Regardless of how the data iscollected or the source or sources of the data, the system may aggregatethe data to create a repository of information representative of gameplay characteristics and other data of players and their associatedcharacters.

For example, through an API exposed by a game, the system may retrieveinformation pertaining to the types of characters associated with aplayer and certain attributes of those players, such as characterlevels, experience points, attributes, the rate at which thisinformation changes, the players and characters that the player playswith, the types of monsters or characters with which the player engagesin battle, the types of spells or abilities that the player frequentlyuses for different types of characters, the frequency with which playersengage in battle, and so on. As another example, this and other types ofinformation may be determined by intercepting and processing data fromvideo RAM.

As another example, players may provide player preference anddemographic information directly, such as the types of players theplayer wishes to play with, where the player resides, whether the playerwishes to play with local players, and so on. Based on an analysis ofthe aggregated information, the system can, as discussed in furtherdetail herein, determine a player's style of play and skill with respectto different characters, tailor game play or opportunities to meet theplayer's desired style of play, and types of characters and the types ofplayers that may be matched with the player to enhance the player'soverall gaming experience.

In one example, the system first identifies a particular gameinteraction, such as an exchange between a character and a merchant or abattle between a character and a monster. Furthermore, the system mayidentify at least one character attribute, such as damage caused, andtrack the at least one character attribute during the identified gameinteraction. In some embodiments, the system may also track attributesof a player during game interactions, such as how often the playerconverses with other players in the game, etc. As the character engagesin various game interactions, the system can track various characterattributes associated with the character and track the progression ofthese attributes. For example, the system may store the attribute in adatabase or other data structure in association with informationreflecting changes to the attribute. The system may also store atimestamp for each change indicating when that change occurred. Thetimestamp may be based on the character's or player's time in game(i.e., how much time the character or player has spent interacting orplaying in the game) or real time. In this manner, the system can recorda history of the attribute for further analysis, such as the rate atwhich a character increases in level, ability, etc. Furthermore, thedata can be analyzed for trends and statistically significant values,such as a relatively high or low rate of improvement or loss whencompared to other characters or players. In this manner, the system canidentify certain types of players, such as players whose characters tendto increase in level or experience points at a relatively high or lowrate, tend to obtain or lose gold or other currency at a relatively highor low rate, tend to die at a relatively high or low rate, etc.Furthermore, the system may track character attributes of othercharacters as well and generate one or more rankings for the charactersbased on the character attributes. Once the system has adequateinformation about the character and/or a player associated with thecharacter, the system may attempt to identify complementary, for examplesimilar or like-minded characters and/or players or characters orplayers that otherwise likely enhance the collective gaming experience,and notify the player associated with the character of the identifiedcharacters and players.

Referring to FIG. 6A, details of the game system in some embodimentsshow that the client 140 includes a game program 615 which executes oneor more modules. The game program can include a communications modulefor exchanging information (e.g., game packets) with the game server530, a graphical user interface module, a graphics or scenery generatormodule to generate graphics and imagery in the game, a combat enginemodule to execute combat commands and provide instructions fordisplayable results, as well as other modules, such as a physics enginemodule to represent, in the virtual world, responses to events so thatdisplayed results appear more lifelike. The game program 615communicates with the game server 530 via the network 110. The gameserver 530 includes one or more game programs 620. As noted herein,multiple servers, each running one or more game programs, are possible,particularly where each game server and associated game program(s) canrun different games, the same game across different zones or geographicregions, the same game across different guilds or groups of affiliatedplayers, and so forth.

In one example, an information collection processor or module 625, suchas a packet parser and analyzer, may be used to analyze data from thegame, such as the packets 500 exchanged within the system. Theinformation collector analyzes data (e.g., packets or aggregations ofpackets), to extract certain data to help perform functions describedherein. As shown in FIG. 6A, an information collector can be in theserver 530, the client device 140, or in other locations, such as on acomputer 635 in communication with the client device 140 via a LAN 630.Alternatively or additionally, a module 625 can be on a WAN proxy server640 coupled to the network 110.

Although the example system is described herein as including aninformation collection module for collecting information related to gameinteractions and player characteristics, other methods for collectingsuch information are contemplated. Other methods may include, forexample, reading data structures directly from storage or memory, suchas a disk/SSD, RAM, video RAM or other memories. As another example, thesystem may collect the information from the game program itself via, forexample, game program APIs to directly interface with the game program,additional subroutines or functions to access game program variables,databases and other data structures associated with the game program,system states, return values, and other game information. As anotherexample, the system may intercept interprocess communications related togame interactions. Once the information has been collected, the systemcan then aggregate this information (e.g., locally, at a remote server,etc.) for further processing to characterize players and identify otheraspects or statistics related to player gameplay, such as how the playercompares to other players, how the player's gameplay has changed overtime, etc. These characterizations, statistics, and aspects may, forexample, be used to identify similar types of players, players with moreskill, player playstyles, and other information as further describedherein.

In some embodiments, regardless of where the information collectionmodule may be located, it is coupled to a local database 665, and storesdata captured and aggregated by the module. Each of the informationgathering modules intercepts data (e.g. packets) to extract data andprovides the extracted data to a characterizing server 655 associatedwith the game server 530. A characterizing server determines the playcharacteristics of a player based on, for example, that player'sinteractions with one or more games. Information representative of thoseinteractions is captured, for example, from game packet information,RAM, video RAM, information exposed through an API provided by a game,interprocess communications, data structures maintained by the game,function calls to the game or associated software, etc. Once collected,the information may be aggregated and provided to a characterizingserver for analysis. A characterizing server may include components,modules, and data structures for storing captured and aggregatedinformation and analyzing the information to develop a profile forplayers and/or characters. Alternatively or additionally, a third partycharacterizing server 645 may receive the aggregated packets or dataextracted from the packets, where the third party characterizing serveris coupled to the client device 140 and server 530 via the network 110.Furthermore, the game program 615 running on the client 105 may includea characterizing module (not shown) to locally analyze or pre-processcaptured information and provide the results of such analysis orpre-processing to the network. In this manner, the load on game serversis reduced as they are not responsible for analyzing all of the capturedgame information. In this alternative, the parser module performs localanalysis before shipping logs of its analysis to, for example, the thirdparty characterizing server 645 or the game characterizing server 655.

Indeed, aspects of the player characterization process described hereinmay be performed and distributed among various components within thesystem. For example, the characterizing module on the client device 105may do some initial or even all analysis and data aggregation, such asby omitting redundant data and populating a data structure related tothe gaming interactions representative of, for example, the state of thegame or a character, such as a log file, which can then be sent to thethird party characterizing server or the game characterizing server forfurther analysis. Such data may be stored in the local database 665.Such local databases 665 may include raw or partially processed data,and the third party characterizing server 645 and game characterizingserver 655 may store more refined, manipulated or fully analyzed data inthe profiles database 650 and 660, respectively. Of course, it ispossible that the fully-refined data is generated at and stored at theclient device 140, and the player may have the option of whether to postor forward on such information. For example, if the client devicedetermines a type or category for a player (e.g., crafter, grinder,etc.) based on a local analysis of that player's gameplay, the playercan determine whether he agrees with that determination, and if so, sendan indication of the determination to a characterizing server forstorage. Alternatively, the player may be able to change or adjust thatcharacterization to better suit that player and provide better matcheswith other players on the network. In some embodiments, some or allclassification and analysis is performed at and stored at the localclient device and users control the use and release of their owninformation as further described herein. For example, the characterizingserver 645 and/or 655 may be implemented as a local client or nodemodule that processes and analyzes data collected to identify anddetermine user, character, and/or item classifications and otherinformation as further described herein. The profiles database 650and/or 660 could also be stored and controlled at the local client orindividual nodes rather than over the network. Game publishers, otherusers, various programs, or other applications may access this data in acontrolled manner via standard APIs or other means according to privacypreferences and/or other constraints set by the player to govern thisinformation release and use. For example, in some embodiments, playersmay make some or all of their activity data, item data, metadata,classification information, and other information described hereinavailable to other players or to game applications, for example tofacilitate matching. When looking for a group or an activity partner orother similar individual(s), the player may make their informationavailable, and matching software, either at the local client or throughone or more other third party applications hosted on the network,analyzes this information to determine other suitable matches based onsimilar information provided by other users. A user could also implementone or more policies or rules indicating that some subset of or all oftheir information should be made available automatically to certaintypes of requestors, such as applications of a certain type (e.g.—fantasy MMOGs), applications created by a certain publisher, users of acertain type or classification or satisfying certain criteria, etc.Different policies could be associated with and used for release ofinformation to different types of requestors. Thus, users in such anode-based or distributed system have the ability to “opt-in” on acase-by-case basis with respect to specific uses, applications, etc. orcontrol release of their information via a policy or rules based systemregarding use of their data for classification and other purposes asdescribed herein.

In one example, the module 625 in the client device 105 may capture rawdata (e.g. —by polling every two seconds or otherwise periodicallysampling for the location of the player's character), every action theplayer takes, and every button pressed, as well as all chatcommunication. The analysis module can distill captured data beforesending it out over the network. For example, if the player's charactergenerally does not change location by a certain percentage or within acertain radius over a certain period of time, no further location datamay be sent since the player's character has been in the same locationfor a certain period of time. As noted above, rather than provideprecise coordinates, the module can track movement within zones definedon the map to help provide a less granular representation of thecharacter's movement. In some examples, the system may allow a player toopt-in or opt-out of the collection of any of the information orcharacteristics described herein, such as the player's movementthroughout a world or the player's associations with other players. Forexample, a player may allow the system to track the player's success inbattles but not allow the system to monitor which players that playercompetes or completes quests with.

Referring to FIG. 6B, an example of the information collector module 625is shown as including a data/packet interceptor 626. The data/packetinterceptor 626 receives data, e.g., packets, in the stream ofcommunication, and helps identify data to be analyzed versus that/thoseto ignore. A decoder/decrypter 627 can decode or decrypt received data,if the data is encoded or encrypted. As explained below, alternativesare possible, such as accessing already decoded data directly frommemory. Although various components are shown as comprising adata/information collector and analyzer, one skilled in the art willunderstand that any or all of these components may exist independentlyof a data/information collector and analyzer. Furthermore, thesecomponents may analyze data collected from sources other than packets,such as RAM, video RAM, information exposed through an API provided by agame, interprocess communications, data structures maintained by thegame, data structures maintained by the game, function calls to thegame, game server, or associated software, etc.

A data compressor 628 may analyze data (e.g., multiple packets, oraggregations of data) to eliminate redundancies and analyze or processonly that data that include significant differences. In someembodiments, the system analyzes only a subset of data collected, forexample data exceeding a certain threshold or satisfying certaincriteria, such as movement data beyond a threshold or communicationcontent satisfying certain criteria. For example, as noted above, if acharacter stays within a given location, and thus the coordinates ofthat character do not vary beyond a threshold, then the data compressor628 may not send out subsequent packets or portions of such packetsrepresenting no change in movement. However, if the character is in atavern and communicating with multiple other characters, then all of thechat or other communications would be included or, in some cases, onlycertain relevant content of the communications included. Thus, in someembodiments, the system performs differing analysis based on differinglocations or contexts. For example, the system identifies a first useror character at first location and performs one or more first actionsbased at least in part on the first location and identifies a seconduser or character at second location and performs one or more seconddifferent actions based at least in part on the second location. Thefirst and second user may be different users or they may be the sameuser. Exemplary actions performed include classifying or otherwisedetermining user or character characteristics, performing user matching,or other functions as described herein. However, even such chat could becompressed to delete pronouns, articles, and commonly used terms, whichwould not be forwarded on to a language analyzer 631, described herein.

A movement/input analyzer 629 may analyze certain portions of receiveddata (e.g. each packet) that deal with movement of the character orinputs made by the player. For example, the movement/input analyzer 629may analyze data to determine that the character is at a location formany minutes, is spending time changing items and inventory orrepeatedly doing the same series of inputs, and so on. As a result, themovement/input analyzer 629 can make an estimate that the player is, forexample, trading items at an auction/store or creating arrows.Alternatively, the user may be in roughly the same location, butproviding multiple inputs corresponding to battle. Thus, themovement/input analyzer understands that the player is engaged incombat.

Thus, the movement/input analyzer 629 can help determine thecharacteristics of the player, such as whether the player spends manysessions crafting, versus a player who spends much of his time fighting,while another player spends much of his time exploring the virtualworld. The movement/input analyzer 629 can analyze data for a session,such as a two to six-hour session, and then generate a playercharacteristic or condensed log file for that session to help the system(characterizing server) determine the play characteristics for thatplayer. Thus, as noted above, if the movement/input analyzer 629, whenanalyzing data, determines that the player's character moved around thevirtual world during that session, but engaged in little combat, andstayed for no more than a few minutes at any one location, then themovement/input analyzer may characterize the player as an explorer, andprovide such characterization to the characterizing server. Themovement/input analyzer may also analyze distances traveled, locationsvisited and frequency of visits, whether the locations visited are newor repeated, etc. The movement/input analyzer 629 can compare data oraverages of data, to player averages within that virtual world acrossall players. So, if, during a four-hour session, most players visitedonly two to three zones, but the current player visited eight, thesystem would again characterize the player as an explorer. As anotherexample, if the movement/input analyzer determines that a player uses acharacter to perform repetitive actions and increases a particularattribute or characteristic at a higher rate than average, the playermay be deemed a grinder.

In some embodiments, the information collector and analyzer 625 may alsoinclude a language analyzer 631, that includes a spelling/grammaranalyzer 632, a term analyzer 633, and a sentence analyzer 634. Thecomponents of the language analyzer may analyze spoken and/or writtenlanguage. The spelling/grammar analyzer 632 can analyze the spelling orgrammar used by players to determine whether a player often misspellswords or uses nonstandard grammar, because such players may often wishto play with other players that share the same vernacular or lexicon.For example, some players may wish to play with other players who spell90% or more of their words correctly, whereas others may frequently usecontractions, texting abbreviations (e.g., “LOL” for laugh out loud or“UR” for you are).

The term analyzer 633 can analyze given terms in the text communicationsto identify profanity, racist, homophobic, or other derogatoryterminology, or other potentially offensive language. These playersshould be segregated from children or players who may be offended bysuch language. Further, the term analyzer 633 may analyze the textcommunications for elite speak (“I33tspeak”), which is a specializedform of textual communication often used by players who considerthemselves highly-skilled or elite (spelled “I33t”). In some cases,players may use I33tspeak solely for comedic effect. Such players maysubstitute a “0” (zero) for a lowercase o, a “3” for a capital “E”, andso forth. Such players who use these terms may wish to play with otherplayers who likewise use similar terminology. The term analyzer maysimply also count the number of letters in words used and determinewhether a player uses longer, larger words of 10 letters or more, and ata frequency above the average for a given language (e.g., English) andregion (e.g., New Jersey), which can help identify a higher educationalbackground, and thus may indicate that the player may wish to play withother players with a similarly high educational background.

While the spelling/grammar analyzer 632 and term analyzer 633 mayperform simple comparisons of individual words or short phrases to astored dictionary, the sentence analyzer 634 may provide a more complexanalysis of communications between players. For example, the sentenceanalyzer 634 may determine whether a player uses short, pithystatements, or longer descriptive sentences. Analysis at the sentencelevel can help determine cultural and ideological preferences, whichagain can help provide better matching between players.

More generally, the system may also include an interaction analyzer thattracks social interactions between the player and other characters inthe game. In general, the system can characterize user behavior withinelectronic games, virtual worlds or other online endeavors by obtainingdata regarding a user's communications within the game/world/endeavor.The system, from the obtained data, analyzes thresholds and otherquantifiable or other information regarding word choice, word length,sentence length, grammar/spelling errors, number of different playerscommunicated with, and/or other data described herein, and therefrom,determines a character profile for the user based on that analysis. Forexample, the system may track the number of separate socialinteractions, such as conversations, that the player has over aparticular period of time. The system could aggregate and analyze thecollected information and classify players as “social” or “non-social”and notify the players of any players who are similarly interested inthe social aspects of the game. This provides a benefit to both types ofplayers because a non-social player is likely to be annoyed playing witha very social player and vice versa.

While the various components 626 through 634 are shown as part of themodule 625, some or all of these functions may be distributed amongcomponents within the system 600. For example, the language analyzer 631and movement/input analyzer 629 may be in the server 530, with thebalance of the components in the module of the client device 140 orcomputer 635 or 640. Similarly, the game characterizing server/module655 as well as the information collection module 625 and other modulescan also be located on the game server 530 or at other locations in thesystem. Where particular components are located may depend on bandwidth,latency, and other factors. For example, it may be preferable to havemost or all of the functions of the information collection module andanalyzer within the gaming server 530, which can result in some of thelowest latency (since numerous packets or information need not beexchanged between the client and server), and which result in a muchmore real-time gaming experience with the player. As noted above,components can be located within any network component, distributedamong components. Indeed, as noted above, a different architecture mayalso be employed, such as a peer-to-peer architecture. Further, whilecharacterizing servers 645 and 655 are shown as separate devices, thecharacterizing server functionality can be performed at the clientdevice 140. Much of the architecture may depend upon certain gameplayissues such as latency, security, etc.

If the data is encrypted or otherwise secured, or if ease in processingdemands such, the client device 140 may, for example, access datadescribed herein not in its received or raw form, but after the data hasbeen processed by the game program 615, or as inputs to the game programare received by the player. Such data may be stored in RAM, and thus,rather than employing information collection module, the movement/inputanalyzer and language analyzer functionality may be employed to directlyanalyze data stored in memory of the client device 140. Alternatively oradditionally, such movement/input analyzer functionality, languageanalyzer functionality, or other functionality described herein mayaccess memory on a video card of the client device 140. In theseinstances, the raw data itself is accessed and analyzed, before or afterit has been packetized.

Referring to FIG. 6C, an alternative system configuration is shown wheremultiple client devices 140 are again coupled to multiple game servers530 via a computer network 110. However, in this example, a portalserver 670 helps coordinate communications between the client devicesand the game servers. The portal server 670 can coordinatecommunications between client devices and different game servers 530operated by multiple different companies, between client devices andgame serves 530 of the same company, or combinations thereof. The portalserver can be a game portal that helps match players and their clientdevices with appropriate game servers, where the game servers may beoperated or hosted by different companies or organizations. Thus, theportal server may include a player data database 675 that includesinformation similar to the profiles databases 650 and/or 660 of FIG. 6A.As explained herein, the game server helps to identify quests, games orvirtual worlds for players or advertisements or product recommendationsto be displayed or presented to a player. The game server cancommunicate these suggestions to the players via the network 110 andclient devices 140, such as via chat or other communication methodsprovided in a game.

Alternatively or additionally, the portal server or other communicationsmodule can communicate with players via an alternative communicationnetwork 677, such as via SMS, MMS or other, similar messaging, viainstant messaging, via voice messaging, facsimile, postal mail,broadcast or cable television, or other forms of communication. Thus,the alternative communication network 677 can include standard telephoneor circuit-switched networks, cable television distribution network,wireless or cellular telephone network, and so forth. As shown, theportal server 670 may likewise communicate with players via thealternate communication network 677, and in this example, the portalserver may take a more active or direct role in communicating withplayers to notify them of new games, new quests in games, new parties tojoin, and so forth, where such games need not be tied to a particularnetwork location, games manufacturer/distributor, and so forth. Theportal server (or game server) can provide communications to the playervia other devices, such as to a smart phone or office computer viae-mail, by, for example, sending an e-mail to an e-mail serverassociated with other devices associated with the player (e.g.“non-gaming devices”).

A portal server 670 can also help provide additional services toplayers, where such services are provided by other online resources. Forexample, the portal server 670 may work with a recommendations server680 and preferences database 682 to provide improved recommendations orpreferences to players. For example, the portal server 670 may gatherplayer characterizing data described herein and provide it to therecommendation server to receive therefrom additional data to help incharacterizing and/or matching the players or providing recommendationsto the players. Thus, in this example, the portal server may providequestions to the players regarding favorite books, movies, music,television shows, or other games, and provide such input to therecommendation server 680, which in turn can provide data regardingother games, themes or media which the player may be interested in.

The portal server 670 can work with online merchant servers 684 to helpsuggest goods or services to players based on a player characterizinginformation gathered and analyzed, as described herein. The onlinemerchant server 684 may be coupled to a products database 690 andtransactions database 686. The online merchant server can include, forexample, an auction or sale site for selling virtual objects or digitalgoods found, acquired or won in games.

As shown herein, the system can suggest games or quests to a player, butmay not have information regarding the player's availability. Forexample, the system may call, email, text, send an in-game message, orcontact the player by some other means. Therefore, the portal server 670may communicate with a scheduling/event server 692 (and associatedscheduling database 694), to determine availability of the player or toaccess data regarding upcoming games or events. Further, the portalserver 670 can access data in the scheduling database 694 to providerecommendations to the player regarding upcoming events unrelated to agame, such as movie openings that may correspond to the player'spreferences, conventions related to a player's interest, and so forth.

The portal server 670 may communicate with other servers 696 and otherdata 698. For example, one of the other servers can be an advertisingserver that provides advertising to the players either in a game oroutside of a game. As explained below, the portal server may permit aplayer's characters to move between games and virtual worlds, eventemporarily, without losing experience, equipment or other characterstatistics or possessions. The system may allow a player to opt-in toreceive information or notices, such as advertisements or otherpromotional materials, related to products that are of interest toplayers with similar characteristics or purchased by other, similarplayers (via links and exchange of information with ecommercesites/servers). If a particular quest, location, item, product orservice becomes popular to a particular demographic, the system mayadvertise the product or service to members of that target demographic.

Furthermore, the system can aggregate players based on the determinedclassifications described herein, and offer selected offerings forproducts or services targeted to those aggregated players. Thus, forexample, the system may identify a set of players characterized asexplorers living in the New York City area, all of whom are playing anonline game, and all of whom are in a level or zone having a jungletheme. The system can then offer to that identified set of players adiscounted trip to visit the Amazon rain forest, together withdiscounted round-trip airfare from the New York City area, hotels,excursions and other offerings. The system, after having characterizedplayers, can simply identify products and services, obtain bulkdiscounts to those products/services, and then offer those bulkdiscounts to certain sets of characterized players who would more likelythan not be interested in these discounts. In some embodiments asfurther described herein, users/players may maintain theircharacterization information at their local client or another locationto which they control access, thereby enabling them to control releaseof their information to such commerce or advertising software ornetworks. Thus, via an API or other means, a user may elect to allow aretailer access to some or all of the user's information, for example toreceive discounts of interest, offers, and other information from theretailer. A user's purchase history, in addition to user activities andother classification information described herein, may also be stored,for example to improve the user experience, facilitate userclassification, improve hardware usage, etc.

Alternatively or additionally, the portal server 670 may allow a playerwho has acquired gold, virtual currency or other points or items in agame or other online endeavor, for example via certain in-gameachievements or experiences, to exchange it/them for real-world items,such as for pizza or other food, dollar credits to be used to purchaseitems at an online store (such as Amazon.com), to download other gamesor levels for games, etc. A player could thus pay for a tangible orphysical real-world item using gold earned in-game or could exchange afavored item, for example a magic sword or piece of armor, for realworld items.

The system described herein can also provide product recommendations forplayers. The system can access not only player data as described herein,but also other player behavior information and recommend products toplayers based on other products that similar players have purchased orliked. For example, the system can recommend to a grinder-type playercertain music, movies, other games, or any products or services that asimilar grinder-type player has purchased and/or enjoyed. Moreover, thesystem can provide an interface to a commerce engine to promote productsfor certain types of players, and even provide product placement forthose products. For example, the system may recommend to anexplorer-type player that he may be interested in a subscription toNational Geographic magazine, whereas a player who often likes to drivevehicles in the game may be recommended an off-road automobile magazine.For example, energy drinks may be advertised in a game to a powerplayer, whereas particular brands of tea may be recommended to anexplorer-type player.

The player characterizations described herein provide a more detailedbehavioral understanding of consumers beyond typical demographic datagathered by marketing data collection sites. As a result, the system canprovide much more accurate targeting of products to players. Thisinformation can be reported to online advertising sites such asDoubleClick, to further drive more targeted and relevant advertising toplayers. By employing user identifiers such as cookies or “web bugs”linked to unique user IDs for each player, a player's online behaviorcan be matched to in-game behavior, which may further enhance thecharacterization of the player described herein, as well as thetargeting of advertising to that player through online ads, productrecommendations, and so forth.

The system can cross-reference data obtained and characterizations madefor a player with other information about that player to thereby providea richer experience for the user in other online activities. Forexample, the system may ask a player for permission to cross-referencedata obtained during a game with a user's Amazon.com account. Asdescribed herein, this data may be stored at the local client andrelease controlled by the user, or stored elsewhere on the network. Bycomparing data obtained through game play with data obtained throughshopping behaviors at online shopping sites such as Amazon.com, both thegame and the shopping site may provide better recommendations to theuser. If, for example, a fellow player having similar characteristics asthe user purchased certain products at Amazon.com, then Amazon mightlikewise suggest those products to the user. In other words, rather thanhaving two separate recommendations engines, the user can be providedwith a richer experience in both the game and the online shoppingexperience (as well as other online endeavors), if the data from the twowere merged or shared. A user may wish to enhance both experiences byallowing the sites to share data among them.

Profile Data Structure

Referring to FIG. 7, an example of a data structure 700 includesplayer/account characteristics 705 and one or more game or activityelements, e.g., character avatar or character data elements 710, 712,720 and 722, purchase history (not shown), or other activity history orinformation described herein. The profile data structure 700 can bestored at various locations, such as in the player data database 675,the profiles database 660 of the server 530, or the profiles database650 of the third party characterizing server 645. Further, the datastructure 700 may, in an alternative example, be stored on the clientdevice 140. Further, the profile data structure can be stored inmultiple different locations, or distributed among the locations.Information stored in a data structure 700 may be personal, such as age,education, income, etc. or game-specific, such as character personalityinformation, game server information, etc.

The player/account characteristics 705 generally has a 1:1 mapping tothe player, whereas each player may have one or more identifiers orpersonas or characters for one or more games or activities. Theplayer/account characteristics 705 can include network or deviceinformation, such as an IP address for the client device 140, or otheridentifying client device information. The player/accountcharacteristics 705 can include information that would rarely change forthe player, such as a time zone or location 716 in which the player islocated, the player's birth date (from which age 717 may be determined),and other information regarding the player, such as the player's gender,race, nationality or sexual preference. The player/accountcharacteristics 705 can include information regarding gameplay habitsfor the player, such as typical play time 718 during which the playertypically plays online games, a play frequency 719, indicating whichdays of the week the player plays or how often each month the playerplays, and a play duration 720, indicating how often the player willtypically play during a given session, such as 30 minutes, six hours,etc. In some embodiments, some or all of this information may also oralternatively be stored in one or more data structures associated withvarious games or activities engaged in or with characters or avatarscontrolled by the user. For example, a player may spend more time persession playing a World War strategy game than a fantasy-themed game,and thus the data structure can track both.

Further, a type data field or element 721 can indicate the type ofplayer, which is a rough characterization of the player's gamingtendencies. This information may be player specific and stored as anassociation for the user generally and/or it may begame/activity/character specific and also associated with particulargames/activities engaged in and/or characters played by the user.Examples include an explorer (someone who likes to visit multiplelocations within a game), quester (someone who likes to solve or achievequests to gain experience points, gold or items), a power gamer (wholikes to battle monsters frequently and gain levels), a crafter (someonewho creates, fixes or improves items), a socializer (someone who enjoysengaging in social interactions with other players), or a role-player(someone who likes to stay in an appropriate role associated with thegame and interact with other players). As another example, player typesmay be based on preferred weapons or other abilities, such as meleeweapons, crossbows, traps, attack spells, and so on. As describedherein, while the profile data structure may only associate a singletype to each player, most players enjoy some combination of these andother types, and thus the types may be in order from most preferred toleast preferred, or have percentages associated with each type. Forexample, a given player may be 50 percent quester, 20 percent explorerand 10 percent power gamer.

The player/account characteristics 705 can include other informationregarding the player, as noted herein, such as an educational level 722,income bracket 723 and/or exclusion 724, which can indicate certaincharacteristics or traits that the player wishes to avoid (e.g. anyonefrom work or has a domain name associated with the player's employer).Additionally, the system may allow a player to exclude specific playersor other players associated with that player. For example, if player Ahas had a bad experience with player B, player A may list or identifyplayer B as an “excluded player” so that the system does not matchplayer A with player B. Furthermore, player A may select to exclude anyof player B's friends so that player A is not matched with player B'sfriends or associates. In some embodiments, friends of player A or otherindividuals authorized by player A may access or otherwise inheritplayer A's exclusion/inclusion/friend list, notes or information kept byplayer A regarding other players, or other filters (chat, etc.) orsimilar settings. Some or all of this information could be used by suchfriends or other authorized individuals to create or add to their ownlists, notes or information on other players, account filters, and othersettings. Thus, in some embodiments, a first user generates informationregarding other users, for example an inclusion or exclusion list, notesregarding other players, etc. This information is stored in a first datastructure associated with the first user. A second user, authorized bythe first user, accesses the first data structure and second datastructure associated with the second user is created or updated withsome or all of the information contained in the first data structure.Users therefore can learn from the benefit of their friend's experiencesinteracting with other players among other advantages. Users may alsomay also allow or otherwise permit inheritance of permissions forfriends of friends and other social contacts. Similarly, users may alsobenefit from the virtual and real world experience(s) of friends andfriends of friends by viewing or otherwise accessing recommendationsregarding game quests, other players, shopping, dining, tourismattractions, lodging, etc. The player/account characteristics 705 mayalso include information on the account's subscription type. Forexample, a game may provide subscription tiers at different prices, withadditional features and benefits offered to accounts subscribed to ahigher tier.

Each player may have one or moreavatars/characters/personas/identifiers/aspects in one or more games oractivities. In the data structure 700 of FIG. 7, four characters areassociated with the player, two characters 710 and 712 associated with aGame 1, and two characters 720 and 722 associated with a Game 2. Each ofthese characters is defined by multiple data elements, such as a name740, identifier 741, class 742, level 743, personality 744 (which insome games may be an alignment, guild association, or other affiliationor trait), equipment hash 745, friends list 746 or other data element.The equipment hash is an algorithmically generated number or othervariable, described in detail below, that takes or assigns a value toeach piece of equipment in the character's inventory and generates aresulting composite number/variable for all items in inventory. Theequipment hash may be a unique number, but may be more simply theaddition of all parts associated with each piece of equipment. Thus,plate mail armor may be worth 10 points, and if magically enhanced witha plus two value, it would be worth 12 points, a battle axe may be wortheight points, with an additional three points for fire damage itprovides, and a ring that provides 20 percent acid resistance is worthfour points, for a total of 27 points. In some embodiments, thisinformation is used as a threshold to identify matches, classifyplayers, qualify or disqualify users from certain experiences, and forother similar purposes further described herein.

A friend list 746 (and/or an exclusion list) may simply be a list ofcharacter names, user names, or other identifiers for players orcharacters with whom the character has interacted or played with in thepast. A friends list or exclusion list may be game-based (e.g., a listof players or characters with whom a player has interacted within aparticular game) or “global” (e.g., a list of players with whom aparticular player may interact with outside of the gaming environment).In this manner, a player may be notified of any of their friends who areonline, regardless of the game or activity in which their friends areengaging. Data structure 700 may also include additional informationspecific to the particular game. For example, the data structure maystore an identification of a server, which may represent a URL or othernetwork address for the game server 530, or the portal server 670 or anindication of a game subscription type (e.g., yearly, month to month,etc.) associated with a player or character.

Alternatively or additionally, the friend list 746 may also includelinks to social networking profiles, such as those on Facebook, tothereby permit the system to access lists of friends on these socialnetworks. As a result, the system can not only generate lists of friendswithin the system, but access data regarding additional friends,external to the system, via these social networking sites. As a result,the system has access to all fields and other data provided by suchsites, such as affiliations, occupations, interests, etc. Informationsuch as religious affiliation, nationality, ethnicity, foreign languagesspoken or understood, native languages, students of certain languages,etc. may be obtained. Further, other social network databases may beaccessed by the system, such as the World of Warcraft finder or othergame/activity finder databases that may exist now or arise later.

The system can provide weighting to an inclusion or affinity list, suchas a friends list, for example so that the system will more likely matchthe player with someone else who may be on the player's social networkfriends list, rather than another person who is not on that list.Likewise, the system can match the player with someone who has afirst-order or direct connection with a person on an external friends orcontacts list, rather than someone who is two or more orders removed, orprovide decreased weightings as a potential match for the player is moreand more removed from the player's circle of contacts/friends. Thus, insome embodiments, the system associates with a first user a first datastructure associating a first set of users with one or more identifiers.For example, a user could be identified as a friend, as a family member,as a friend of a friend, as a co-worker, as a classmate, as an enemy, asan individual the user does not like, etc. The system also associates atleast a second user, the second user being a user identified in thefirst data structure, with a second data structure associating a secondset of users with one or more other identifiers. When performingmatching or other classification based activities related to the firstuser, the system accesses the second data structure, and increases (ordecreases) the likelihood of matching or classifying the first user withone or more users in the second set of users in the second datastructure. For example, if a user in the second set of users isidentified as a friend (of a friend identified in the first data set),then the system might increase the likelihood of matching the firstplayer with that user by 50% (versus the average player). If a user inthe second set of users is identified as a friend (of a family memberidentified in the first data set), then the system might increase thelikelihood of matching the first player with that user by 75% (versusthe average player). Of if the user is an enemy (or part of an exclusionlist, or otherwise disliked, etc.) of a friend in the first data set,then the user might have their matching threshold lowered relative tothe first user or entirely excluded.

A profile data structure 700 in FIG. 7 is only an example. Alternativeor additional data elements or fields may also be included. For example,the profile data structure 700 may store data on individualcharacteristics or attributes of the character (e.g., strength, wisdom,etc.), individual quests, activities, or tasks that the character hasaccepted and whether those quests are in progress or completed, theamount of time it took to complete each quest, other characters withwhom the quest was completed, and information on any customization ofthe character's current or prior appearance (e.g., hair color, hairstyle, body size, etc.). Additionally, the profile data structure maystore a metric or other indication of various “efficiencies” associatedwith a character, such as how effectively a player uses spells or itemsor how often a player inefficiently uses spells or items. For example,if the player has the ability to cast a spell that recovers 500 hitpoints but often uses it on characters who are only 300 hit points belowmaximum, the player may be considered less efficient than a player whoalways uses the spell on characters who are 400 hit points or more belowmaximum.

The system may also provide different user interfaces, different levelsor even different games based on the characteristics determined for eachplayer. Thus, a pre-teen girl may receive a user interface with brightcolors, animal themes, and easy to manipulate controls, with fewoptions, which simplifies the experience, and may make it morecustomizable for that demographic. Thus, fewer options than those shownin FIG. 7 and described herein are provided. In contrast, a 30-40 yearold male with an advanced business degree may receive a user interfacethat uses a much more subdued color set, uses well known user interfacetools common with word processing/spreadsheet/database applications, andthat provides more options, so that players in this demographic havemuch more flexibility and options to customize his gaming experience.Thus, all of the options shown in FIG. 7 and described, as well asothers, could be provided.

Match Preferences GUI

Referring to FIG. 8, an example of a user interface or a screen 800 isshown that allows the player to input his preferences, and which thesystem uses to calculate, determine, and provide improved matches forother players with whom the system predicts or otherwise calculates ordetermines would provide an enjoyable gaming experience for the players.As shown, the screen 800 includes multiple user interface elements, suchas sliders that allow the player to indicate a degree of or level ofpreference, for example, between “Less,” “Neutral,” and “More” forparticular characteristics. For example, a player who is not concernedwith the age of the players she plays with may move the “Age” slidercloser to the “Less” end of the spectrum. As another example, a playerwho has a strong preference for playing with other players of a certainlevel of education may move the “Education” slider to the “More” end ofthe spectrum and specify a preferred level of education. Alternatively,the system may by default assume that the player's preferred level ofeducation is equivalent or approximately equivalent to the player'slevel of education. Other examples may include political views, withthis slider ranging between liberal and conservative. In a Personalsection, which includes, for example, certain biographical information,the player can indicate the importance of age to the player in playingwith fellow players. Likewise, the player can use the sliders toindicate the importance of location (e.g. time zone, zipcode/city/state/country), as well as educational level or income. Thepersonal section can also include an exclusion section that allows theplayer to enter text or other information to indicate exclusionarycriteria, such as types of other players that the player wishes not toplay with, domains, network addresses, geography, political views, playstyles, guilds, etc. These can also include the user names or characternames of players that the player has previously not enjoyed playingwith. In some embodiments, the system receives user input or otherwisedetermines that a first user is not compatible with at least a firstcharacter of a second user. Based on this determination, the systemexcludes on or more other characters (some or all) of the second userfrom interactions with the first player in some manner. For example, theother characters might be associated with exclusionary criteria withrespect to the first player, added to a not friends list of the firstplayer, added to an exclusionary communications filter for the firstplayer such that the first player does not receive communications, suchas chat or voice communications, from characters associated with thesecond user, does not match the first user's characters with charactersof the second user, etc. In some embodiments, the system does notidentify the other second player characters to the first user and merelyassociates these characters with exclusionary criteria, for example topreserve anonymity or privacy for the second player's other characters.The system may also prompt a user regarding whether they want to takethis step, for example when a user adds a character to an exclusionlist, the system queries “Do you want to add all other charactersassociated with this player to the exclusion list”. Thus, by indicating(or having the system determine) a lack of compatibility with a firstcharacter a user can avoid interactions with some or all othercharacters associated with the player of the first character. Generally,any inclusionary criteria tracked may also be used as an exclusionarycriterion. The system generally collects and aggregates a robust dataset regarding users. This information is algorithmically generated, usersupplied, etc., and used to include or exclude characters, experiences,users, provide matches, and for other purposes as further describedherein.

The screen 800 also allows the player to indicate how important variousplay styles are, such as whether the player wishes to play with otherplayers who like exploring, prefer a certain style of combat (e.g.,melee, long range crossbow attacks, traps, etc.) play at different playtimes, for different play durations, are focused on gaining levels,prefer raiding games, questing, or crafting. Further, the screen 800allows the player to indicate how important various attributes,criteria, and other information associated with character matches are,such as how important a match in equipment is, how important it is toshare quests with other players, how important it is to have the samelevel, how important it is to have a good compliment of classes (e.g., ahealer, tank, and DPS), and how important it is to play with each ofthese individual classes. Of course, alternative or additionalpreferences can be provided. For example, a player may prefer to have awell-rounded group that includes most basic character classes, and thusmay be most effective at achieving most quests. If, for example, theplayer has a healer character of an appropriate level and temperament,and an existing game has a warrior or “tank” character and a high DPScharacter, that group would benefit from a healer, and thus the system,as described herein, would recommend to the player to join that group.

In some embodiments, a player may be able to configure separateinstances of the user interface for different games, such as differentpreference interfaces or sections of an interface for different games.For example, in one game a player may have a strong preference forplaying with players in a similar age bracket whereas in other games ageis not a factor for that player. In some embodiments, users may alsoimplement various preference policies and associate these policies withspecific games or activities. Thus, a user may have a first preferencepolicy and a second preference policy, the policies indicating desiredmatching criteria, exclusionary criteria, etc. The user may elect toassociate certain games or activities or certain genres of games (e.g.—fantasy-themed MMOGs) with the first policy and certain other games,activities, or genres of games with the second preference policy. When auser engages in games, activities, or genres associated with the firstpolicy, matching, excluding, or other classifications, etc. areperformed using the first policy. Similarly, when a user engages ingames, activities, or genres associated with the second policy,matching, excluding, or other classifications, etc. are performed usingthe second policy. Furthermore, each game may be associated with adifferent user interface. For example, certain character classes may beremoved from the user interface for games that do not include thoseclasses. The system may match players based on weighted characteristicsrelative to the player's own characteristics. For example, the systemmay match players based on weighted characteristics relative tocharacteristics specified by the player, which may or may not beconsistent with the player's characteristics. For example, a 20-year-oldplayer may specify that “Age” is a “More” important characteristic butspecify a “target” age of 40 years old or older. As another example, aplayer in one country may specify a strong preference for avoidingplayers from another country. In some embodiments, the system may use acombination of a player's own characteristics derived by the system orprovided by the player as a player's specified characteristics.

Additional Player Preference Gathering

In addition to the screen 800 of FIG. 8, alternative or additionalmethods of gathering player data directly from the player are possible.For example, when a player first registers with and/or later providespreference information or other information to the portal server 670 orgame server 530, the player may be required or encouraged to complete aplayer preferences screen, such as that shown in FIG. 9. As shown, theplayer in Section 1 can identify one or more languages that the playerspeaks or reads, or in Section 2 provide an age/birth date and anaddress/zip code/neighborhood/city, as well as a gender or sexualpreference. In Section 3, the player can identify an educational leveland possibly schools attended, while in Section 4 identify ethnicity andfaith. In Section 5, the player can identify where he or she grew up,and where he or she considers home. In Section 6, the player canidentify one or more vocations, as well as identify one or more hobbiesor avocations. In Section 7, the player can identify the type of gamerhe or she is or thinks she is, while in Section 8 the player canidentify various interests. In some examples, a player may be able tospecify an interest for playing with players who “know” their gamestyle, such as a player who identifies themselves as an explorer and whois algorithmically determined by the system to be an explorer, asopposed to a player who self-identifies as a tank but behaves more likea healer. Thus, the system receives input from a first player providinginformation regarding a characterization or criterion associated withthe first player as determined by the first player, compares thisinformation determined by the player with information determined by thesystem regarding the same characterization or criterion, and based onthe degree of similarity (or difference) between the player-determinedinformation and the system-determined information, creates, modifies,and/or associates a confidence level, a self-knowledge level, or othermetric with the first player and the characterization or criterion.Based at least in part on this metric, the system performs actions (suchas matching, creating positive or negative correlations between,calculating compatability with, etc.) regarding the first player and atleast second player. In some embodiments, the system also considers asimilar metric associated with the second player in performing theseactions.

Section 9 allows the player to identify certain media and other contentsuch as favorite books, favorite movies, favorite television shows,favorite music and/or favorite games. By identifying other media enjoyedby the player, the system may help to provide a better recommendationfor other players, since other players who may like the same books,movies, televisions shows, music and/or games may similarly like to playwith the player. Such favorite media can be provided as input torecommendations engines or sites noted above. Further, sliders, radiobuttons or other input devices or interface widgets may be provided toindicate how each of the items one through nine rank in terms of “NotImportant” to “Very Important” to that player.

In some embodiments, a player may also identify the activities, games ortypes of games or activities that the player prefers to play and anindication of the characters or types of characters or roles that theplayer prefers to use in each of those games. Moreover, the player mayspecify preferences for each character. For example, the player mayspecify that he not only prefers certain fantasy-style games, but alsothat he prefers to play with explorers when he is using a healercharacter but prefers to play with grinders when using a DPS character.As another example, a player may specify a preference for playing withplayers within 5 years of his age when playing a sports game and apreference for playing with younger players when playing an MMORPG.

In general, a player may specify even more generic aspects, criteria, orpreferences to help aid in matching. For example, the user may specifythat she prefers puzzles to solve, and therefore, the system can suggestgames related to mysteries. Further, she may even specify types ofpuzzles, such as word puzzles, spatial-relation puzzles, etc., which thesystem may suggest. As another example, a user may specify that heprefers problem-solving, and thus may be recommended under the systemdescribed herein not only problem-solving games, but also online eventsdesigned to solicit help from a network of individuals (such as socialneeds or neighborhood collective activities). Thus, the system cansolicit and receive more general information from the user related torecreational desires and types of endeavors that the user likes toengage in.

Referring to FIG. 10, following completion of a game session/zone, orafter playing for a threshold number of hours with a particular group,the system may provide a game survey to the player. As shown at FIG. 10,the game survey may allow the user to provide input regarding theirexperience, for example to select between satisfied and very satisfiedfor answers to a number of questions shown in FIG. 10 in order toprovide information related to their gaming experience. Further, theuser can provide likes or dislikes about a recent gaming experience inSection 8 and 9. Of course, the game server can include alternative oradditional questions.

While not shown, the system can provide an opt-in/opt-out system wherethe player can affirmatively provide permissions as to whether otherplayers can see some or all that player's data. If so, then players maybe able to review profiles of other players to help perform a moremanual method of searching for and identifying potentially compatiblegaming partners. However, in many other instances, the system canautomatically select a likely appropriate fellow player or groups ofplayers with or without indicating why they were selected.

Create Player Data Structure

Referring to FIG. 11, a routine 1100 begins in block 1105 where thesystem creates a player/user record or identifies a player, for example,by obtaining data from an initial registration screen provided to aplayer or user. The initial registration screen can be provided at thetime of registration or at other times and can include basic informationsuch as the game identifier, the player's ID or username, communicationmethods and electronic addresses for the player (e-mail address, SMS/MMSnumber, IM handle, etc.), name, password, address, and so forth. Inblock 1110, the system may obtain data from a questionnaire or GUIprovided to the player. Examples of such an optional questionnaire orGUI are described above with respect to FIGS. 8 and 9. In block 1115,the system stores data obtained under blocks 1105 and 1110 in a datastructure associated with that player.

In block 1120, the system gathers data from gameplay. As noted above,this can include analyzing data provided by the client device 140.Further details are described herein, and also, for example, below withrespect to FIG. 12. In block 1125, the system optionally gatherspost-session data, such as from a survey or other information gatheringmeans. Exemplary information gathering means and surveys are describedherein and, for example, described above with respect to FIG. 10. Inblock 1130, the system analyzes data obtained from the player underblocks 1105, 1110 and 1125, together with data gathered during gameplayfrom block 1120. Further details regarding analysis of such data areprovided herein and also, for example, below with respect to FIGS.13A-13D. Under block 1135, the system updates the data structureassociated with the player based on the analysis. While not shown, theroutine 1100 can periodically loop back to again obtain furtherinformation, such as adjustments to player-entered data under block1110, and data from further gameplay under blocks 1120 and 1125.

Gathering Gameplay Data

Referring to FIG. 12, a subroutine 1120 for gathering gameplay databegins in block 1205 where the system receives information regarding theplayer's game interactions from the player's client device 140 or othernetworked interactions. In block 1210, the system determines whether theplayer's character has moved. To avoid too many computations, movementmay be required to exceed a threshold, as noted herein. If movement isbeyond a threshold (e.g., outside of a predetermined radius, a distance,a Cartesian value, etc.), then the system gathers and stores suchmovement data under block 1215, including position information,direction and rate of movement. If so, then in block 1215, the systemgathers such movement data and stores it for later analysis.

Under block 1220, the system determines whether the collectedinformation includes any chat data. If so, then in block 1225, thesystem gathers such chat data and stores it for later analysis. As notedherein, the system may filter such data to reduce the amount of datastored, such as reducing articles, pronouns, and possibly evenadjectives and adverbs. In block 1230, the system determines whether theplayer has entered other commands. If so, then in block 1235, the systemgathers and stores such further commands. These commands can include“emote” commands, which correspond to a command to the game server tocause the game server to display a particular facial expression ormovement for the character. For example, the player may enter “/grin”,and in response, the character will display a grin expression. Othercommands may be “/bow”, “/sit”, and “/grimace”, and the displayedcharacter will in response bow, sit or grimace, respectively. Othercommands can represent any combat commands, selection of equipment,interaction with objects, trading, crafting, etc.

Additionally, as described herein, the system may track metricsassociated with the timing of sequences and/or events or metricsassociated with a player's gaming interactions to further analyze theplayer's skill. For example, a player may be deemed skilled in combat ifthere is a relatively short period between the time the player engagesin battle and the time the player defeats a monster or monsters in thebattle. In block 1240, the system determines whether the session hasended, and if not, the subroutine loops back to block 1205.

Determine Player Characteristics

Referring to FIG. 13A, an exemplary subroutine 1130 begins in block 1305where the system analyzes the movement data gathered and stored as notedabove. For example, as also noted herein, if the player's charactermoves about the virtual world to more zones than the average player, thesystem in block 1305 associates points, values, or weights to one ormore of multiple player characterizations, such as “explorer”. Thesystem may, for example, identify various zones within the virtual worldand identify the amount time the player spends in each zone.Alternatively, the system may track the distance traveled throughout theworld or each zone or in multiple games, etc. This information may bestored in a player's global profile and/or in game-specific orcharacter-specific profiles. In addition to analyzing the characterindividually, the system analyzes the movement (and actions) of thecharacter when he is in a group. For example, if the character is notassociated with a group, and is frequently moving throughout the virtualworld at a rapid rate, then the system may determine that the playerprefers to explore when playing alone, but when the character is with agroup, recognizes that the character is killing monsters over and overagain (“grinding”), and rapidly moving up in levels, and thus the systemcan provide data or weighting to classify the player as a grinder orpower-gamer when in groups or some combination thereof. Thus, the systemtracks and periodically updates user behaviors and interactions overtime to identify different user classifications specific to a variety ofsettings and contexts in individual games and across multipleactivities.

As described herein, a data structure may track the players' in-gamebehavior, including average movement per game session, zones visited,and so forth. By identifying, e.g. commonly visited zones, the systemcan match the player with other players who also like to frequent thatzone, thereby providing an enhanced playing experience for both of thoseplayers.

Referring to FIG. 13B, an example of a subroutine 1305 to analyzemovement data begins in block 1530 where the system receives movementdata. After receiving movement data, the system employs one or more ofthe processes described herein to analyze the received data; however,some or all of the processes described herein may be optional, andadditional processes for analyzing movement data are of course possible.

In block 1332, the system can compute metrics based on received movementdata and any other data available to the system. For example, the systemmay compute a ratio of distance traveled by the character per gamingsession or divided by an amount of time played within a contiguous blockof time. The system may also analyze for “bursty” movement where aplayer may stay idle for relatively large blocks of time, interspersedwith quick bursts of travel. Such bursty behavior can be compared toplayer averages within the game. For example, an average player may havelarge periods of relative stillness or lack of movement or movement notexceeding a threshold within a certain location of the game (e.g. in atavern), followed by movement throughout a zone. Such movement mayrepresent average play, but a role player may show little movement forlonger periods of time at the tavern/in a town (often in conjunctionwith higher than average chat or text communications), while an explorerwould frequently move about the virtual world. Another player may havesmall movements within one zone, interspersed with larger movementsthroughout that zone (e.g., fighting a monster, then traveling to thenext encounter).

In block 1334, the system can analyze whether the character accessespopular zones above a game-average or other predetermined oralgorithmically determined threshold. For example, the game may defineportions of a virtual world by Cartesian coordinates (as noted above),and assign zone identifiers for such regions. The system analyzesaverage character behavior throughout the virtual world (or in the“real” world, for example via GPS, mobile device locations, or othermeans to identify where users shop, play and engage in other activities,etc.) to identify those zones that are more popular than others. (Whiledescribed herein as analyzing zones, these zones can be of any sizewithin a virtual world, from the size of a room or small discretelocation, to an entire city, country, planet or other larger geographicdesignation.)

The system can employ a frequency metric that compares, for example,popular zones with a given threshold. A game may include popular zonesapplicable to certain level players, where most players, regardless oftheir play style, frequently visit the popular zone at that level. Thus,only players who exceed (or are less than) a threshold amount of timespent in that zone at that level would be recognized as being outside ofthe norm, and thus the system could recognize the player's actionswithin that zone as data useful in helping to characterize the player.Moreover, the system can also analyze actual geographic location of theuser, not only virtual location. Thus, if the player were playing thegame or activity while in a new city, the system can make appropriatechanges to recommendations or actions made by the game, such as offeringadvertisements for food/restaurants local to that geographic location,recommend play with players in that time zone, and so forth.

In block 1336, the system can compare the zones visited by the characterto a table of the zones to flag or weight appropriate characteristics.The system can store a table or other data structure that maps zones toparticular characteristics. Player interactions at various levels andtimes can be compared to this data to further classify and characterizeplayers. Examples of data structures that may be employed are shown inTables 2a and 2b below.

TABLE 2a Zone Characteristics Zone Characteristic Weighting 1 Grinder =+10; Explorer = 2 2 Role Player = +10 if average time spent inzone/section >3x game average 3 Grinder = −10; Explorer = +15 . . . . ..

TABLE 2b Zone-Characteristics Zone Characteristic Weighting 1 Optimallevel = 20; ZonePopularity = 1 2 Optimal level = 20; ZonePopularity = .83 Optimal level = 50; ZonePopularity = .75 . . . . . .

For example, certain zones may be popular among players because theytypically lead to a greater increase in levels per time played thanother zones at that particular level. In some embodiments, for exampleas shown in FIG. 2a , the table or data structure can also mapparticular zones to types of player behavior, because certain zones maybe more appropriate for grinders, and players may have learned ordiscovered that certain zones favor grinding or rapid increase incharacter levels. Likewise, the table or data structure may alsoassociate particular zones with other player behavior, such as certainobscure zones having a different aesthetic or different theme than therest of the game, where such zones are favored by explorers. The tableor data structure can simply flag these zones with an initial or seedcharacterization for the player, or may be more sophisticated andprovide varying weights that are applied to compute a characterizationfor the player (as described herein). Thus, the system may associate onezone with a grinder weight of 10 and an explorer weight of two, whileanother zone may have an explorer weight of 10 and a role-playing weightof five. When these weights are combined with other weights calculatedby the system, the system can provide a more sophisticated and robustplayer characterization.

In some embodiments, for example as shown in FIG. 2b , an optimal levelor level range may be specified for a given zone. Players exceeding acertain time threshold in that zone at sub-optimal levels might becharacterized or weighted as explorers. Players exceeding a certain timethreshold in that zone beyond optimal levels might be characterized orweighted as less skilled players or players desiring less challengesince the player would be overpowered at higher level and the zonechallenge and risk versus reward would be minimal at those levels whichare common indicators of player skill. Players moving from zone to zonein the optimal level ranges might be characterized as grinders. Thus,certain player characterizations or weightings might be calculated asfollows. PlayerMetric=(OptimalZoneLevel(s)/PlayerLevel). In the case ofa range of levels, an average of these levels may be used incalculations. The system could periodically perform and sum or otherwisegenerate time-based data for the player. For example, every fiveminutes, every half hour, etc. Players with values closest to 1 could beweighted as grinders since they generally spend their time in popularzones at optimal levels. Players with values significantly greater than1 could be weighted as explorers. Players with values less than 1 couldbe weighted as less skilled or desiring less challenge.

In some embodiments, a ZonePopularity metric is also employed. TheZonePopularity metric may be predetermined or algorithmically generated.For example, the system periodically takes a census of all game activityin various zones or locations. Player populations are determined as wellas, in some embodiments, other user data and characteristics such aslevel, equipment information, user classification data and other usercriteria, and other information. By comparing the total number ofplayers to the number of players in a given zone, including in somecases additional information such as player levels and such, the systemcan determine, for that particular moment in time, how popular a zone isrelative to other zones, what kinds of and levels of players frequentthat zone, and other zone-related information. Periodically andrepeatedly sampling this information in some embodiments may providemore accurate zone information. Thus, for a given zone, one exemplarycalculation to determine popularity isZonePopularity=ZonePlayers/TotalPlayers. In some cases, a multiplier orother normalization factor may used, for exampleZonePopularity=(ZonePlayers/TotalPlayers)*NormalizationFactor, toprovide a desired range of values.

Thus, once a player is classified, for example as a grinder or anexplorer, the ZonePopularity metric can be used to indicate degree ofclassification among other things.PlayerClassificationDegree=PlayerMetric/ZonePopularityMetric. Forexample, if a player is level 20 and in a zone with an optimal levelrange of 20, then the player metric would be 1 indicating that they area grinder. Grinding in the most popular zone at that level versus a lesspopular zone, however, is not necessarily the same thing. Players in aless popular zone might like variety, exploring, etc. Thus, if theZonePopularityMetric in the prior example is 1 (indicating the mostpopular zone or one of the most popular zones at that level), theclassification degree would still be 1 indicating the player is a solidgrinder sticking to the popular/established path at a particular level.If the ZonePopularityMetric is 0.8, however, the classification degreebecomes 1.25 indicating the player has a propensity for exploration ordeviating from the normal path. The higher the number, the greater thedeviation. Similarly, an explorer type could also be categorized usingthis calculation yielding even higher values. Players could also beclassified or weighted among multiple categories as hybrid types orotherwise. Additionally, other zone weightings and calculations arecontemplated and should be evident to those skilled in the art.

In block 1338, the system can determine whether a common theme isassociated with the character's accessing of zones, and if so, comparesuch zones to another table or data structure to flag or weightappropriate characteristics under block 1340. An example of a datastructure to analyze common themes for zones is shown in Table 3 below.

TABLE 3 Common Zones per Characteristic Zone Characteristic Weighting 1Grinder = +5 if average game time/session = >2x game average 2Social-needs preferred gamer 3 Social-interaction needs gamer . . . . ..

The system under block 1338 determines whether the character exhibitsrepeat behavior based on the received movement data and recognizes thatthe player may commonly access the same zones. By comparing those zonesto the table, a flag or weight can be applied to the player. Forexample, if the player frequently accesses city zones, and spendsgreater than average time in these zones, then the table or datastructure may indicate to the system to provide an initial flag orweight to the player as being a role-player, because role-playing-typecharacters often spend time in cities, chatting with fellow players.Alternatively, certain zones may be designated as “out-of-the-way,”“obscure” or otherwise rarely visited by players, and thus thetable/data structure may flag/weight the player as an explorer if shevisits these zone.

The table/data structure may also have particular characteristicsassociated with certain zones, where such zones may have been designedby the system or the game designer for particular moods or playerpersonalities. For example, one zone may be associated with multiple,fearsome monsters, and have lots of treasure to be gained from theirdefeat, and such zone would typically be more enjoyable to acombative/aggressive/grinder-type player. Other zones may be beautifullyrendered aesthetically, which may appeal to explorers or players whoseek a measure of escapism.

Further, other zones may be associated with ethical/moral/social issuesor concerns, and thus the table/data structure may appropriately flag orweight a player who spends greater than average time in these zones assomeone who is interested in ethical/moral/social interests. (As oneexample, one zone may have oppressed peoples, degraded environmentalquality, famine, or health concerns, and players can receive experiencepoints or other in-game benefits/compensation for solving, rectifying,or ameliorating these concerns.) As yet another example, one zone may bepopulated with fellow player characters or in-game characters that wishto romantically engage with the player's character, befriend thecharacter, or otherwise build an in-game social bond, and thus thetable/data structure can apply an appropriate flag/weight to the playerwho seeks greater social involvement with the game/other characters.

In block 1342, the system updates a database of collective playerbehavior based on the previous analysis. By continually updating adatabase of character behavior within a game, the system can improveaverages discussed herein regarding analyzing and/or identifyingcharacter behavior. For example, if a new zone or region is introducedinto a game, that new zone may become more popular for a given period oftime, which can affect the analysis described above.

In general, many of the analyses of not only zones visited, but othermetrics determined herein may be compared to game averages or othermetrics or thresholds to identify those players who are above the gameaverage for a particular game metric/statistic. While the tables aboveshow a simple numeric weighting applied, regardless of the deviationfrom the average, a much more complex weighting may be applied that istied to deviations from the average. Thus, to determine playercharacteristics, the system may employ statistical analyses withweightings representing non-linear deviations from game averages canhelp to provide greater skew in weighting to particular players. Thus,if a player can be characterized as a “role-player”, and he spends threetimes more per session in a tavern or a city than the average, then thesystem under block 1340 can apply a weighting or multiple that is threetimes greater; likewise, a player who may be characterized as an“explorer”, and spends four times more time per session moving aboutmultiple zones than the average player, then the system under block 1340can apply a four times greater weighting.

Referring back to FIG. 13A, in block 1310, the system analyzes thegathered and stored chat data. As noted above, the chat data canindicate certain player characteristics, such as use of profanity, elitespeak, flowery/archaic language (e.g., use of “thou,” “my lord”), etc.Chat data can provide a strong indication of a player's characteristics.For example, aggressive language, with many exclamations and taunts canrepresent a power-gamer, and thus the system provides points orweighting for power-gaming characterization when found in the chat data.An explorer might not communicate much, whereas a role player wouldlikely communicate quite a bit, often in a flowery manner. As notedherein, the term “chat data” refers to any communication between players(e.g., text, audio, video, etc.). However, if players communicateaudibly, the system may employ speech-to-text to convert such speech totext for easier analysis by the system. In addition, the system may usethe chat data to evaluate characteristics of the player's socialinteractions that are independent of the content of the chats. Forexample, the system may use timing or other frequency data to determinehow frequently a player engages in chats with other players during aparticular gaming session and how long these chats last. Frequent orlong chat sessions could indicate a player who puts a high value onthese interactions. Such a more simple analysis of length and frequency,versus analysis of content, could be preformed with less computationalresources.

Referring to FIG. 13C, an example of a subroutine 1310 to analyze chatdata begins in block 1344 where the system receives communication data.While sometimes described herein as “chat” data, the system can analyzenot only in-game text-based communications, but also voicecommunications (converted from speech-to-text), or communicationsthrough alternate channels, such as via cell phone, instant messaging,SMS, or other forms of communication between players. After receivingcommunications data, the system employs one or more of the processesdescribed herein to analyze the received data; however, some or all ofthe processes described herein may be optional, and additional processesfor analyzing communications data are of course possible.

In block 1346, the system can determine a frequency of communications.In some embodiments, the frequency is represented as an average numberof communications by a user in a given time period or interval.Communications may include textual chat, verbal communications, emoting,and other communications techniques further described herein. In someembodiments, the metric for measuring the frequency of communicationscan be based on a set time interval, such as every 10 minutes, hourly,per game session, and so forth. In general, the system can normalize oruse a standard periodicity for analysis provided herein, although theperiodicity may differ based on the metric. For example, movement datadiscussed above may be analyzed per game session or per hour for playersin a game, whereas frequency of communications may be analyzed in 10minute intervals for players. For example, during the specified timeinterval, the system identifies individual conversations or protractedcommunications between a first player and one or more other players asfurther described herein. The system further identifies periods when auser is communicating in this manner or when a user is performing otheractions and not communicating with other users. The system thengenerates a metric or other information regarding a frequency ofcommunication. In some embodiments, this metric can be compared amongusers to determine relative levels of frequency of communication byusers.

In block 1348, the system can determine a duration of eachcommunication. The duration can be how long a communication with one ormore other players occurs relatively continuously, before a pause lessthan a given threshold. For example, the system may analyzecommunications to see if a subsequent communication occurs within one,two, five minutes or less, and if so, would append consecutivecommunications together to be represented as a single communicationinterval (e.g. a “single conversation”). Some players may have burstycommunication, with long and frequent communications when in aparticular location (such as in a tavern) while others may have burstycommunications in other instances (e.g., while in a battle). Someplayers may have lengthy conversations, whereas others may be morereserved and communicate only when needed and in clipped sentences.These players would be identified and categorized and classifiedaccordingly.

In block 1350, the system can determine an average sentence length percommunication. This can be done by simply counting a number of wordsemployed in a single message. The system may parse longer messages forcertain punctuation, such as periods, semi-colons, etc. Alternatively,the system may employ more sophisticated text analysis algorithms toparse strings of text to identify discrete sentences, and therefrom,count a number of words.

In block 1352, the system can determine an average number of spelling,grammar and/or other errors per communication. The system may simplyemploy a standard spelling checker, grammar checker, or both for eachreceived communication, and identify the number of errors percommunication. The system can also take these errors and performadditional processing, such as number of errors made per hour, permessage, etc. Further, these errors can be compared against averageerrors for all players, or divided based on a given geographic area,time zone, etc. Alternatively or additionally, the system may employ atone checker to analyze the tone of messages to see if the player oftencommunicates in a hostile tone, a conciliatory tone, a flirtatious tone,etc. An example of a tone checker is ToneCheck provided by Lymbix, Inc.

In block 1354, can analyze communications for particular grammars orvocabulary. As described herein, certain players may employ certaingrammars particular to gaming, some players may use profanity/vulgarity,players may employ objectionable terms or phrases, and so forth. Thus,the system under block 1354 can analyze or receive communications tocompare it against stored dictionaries, indices or tables that haveassociated therewith flags or weightings to help characterize players.Thus, use of certain words, phrases, constructions, or grammar canpositively and negatively affect metrics and other informationassociated with a player or character. For example, one dictionary mayinclude profanity or other objectionable terms, and thus use of thoseterms (or use of those terms above a low threshold), can cause thesystem to flag or otherwise characterize the player as using languagethat many others may find objectionable, such as children or theirparents. Similarly, another dictionary may include slang terms commonamong a “hip hop” crowd or other urban-speak, and thus a playeremploying such terminology may prefer to (and may only be understood by)players who have similarly flagged by the system as employing such avocabulary/grammar.

Under block 1356, the system can analyze identities of other playerswith whom the current player communicates. For example, the system cancompare a user ID or other designation of fellow players with whom thecurrent player is communicating, and keep a count of those players tothereby identify, over time, those fellow players with whom the playermore frequently interacts. This can aid the system in determiningwhether the player frequently communicates with the same group of fellowplayers, or enjoys communicating with numerous other, unknown players(e.g. has a high count for a few players, or low counts scattered amongnumerous players). In some embodiments, the system further analyzes thespeech patterns, communications, and other interactions and gameplay offrequent contacts or partners to further categorize or classify aplayer. For example, the system may identify a first player as havingcertain characteristics (speech patterns, interactions, etc.) Whenfrequent partners of the first player share similar characteristics asdetermined by the system, the confidence level is increased regardingidentification of those first player characteristics and also regardingthose second player characteristics. However, the system can providemore sophisticated analysis, such as analyzing the quality ofconversation between the player and other players to identifydiscussions unrelated to game play that may represent a more personalbond between the player and certain fellow players (e.g. by identifyingmentions of personal interests, current events, pop culture references,references to current movies, music, etc.) and so forth. For example,the system may maintain and periodically update one or more datastructures containing information regarding certain topics such ascurrent events, sports, hobbies, etc. Users communicating regarding orotherwise referencing items or information contained in the datastructure will cause the system to create associations between the usersand information associated with the data structure or topic or otherwiseadjust metrics or criteria associated with the user. The system can thusidentify, through communications and/or the nature of thecommunications, if a player is developing a closer relationship with afellow player, and thereby recommend future game play between thoseplayers.

In block 1358, the system determines flags or weightings based on theanalysis. Such flags/weightings are similar to that described above withrespect to subroutine 1305, and as discussed herein. For example, use ofterms “thou,” “my Lord,” and other flowery/archaic language can indicatea role player, and thus the system may flag or weight that playeraccordingly as a role player, flag players who frequently use profanity,and so forth. As another example, a player who uses an aggressive toneand profanity may be flagged as a potential grinder. Other examples areprovided herein. Under block 1360, the system updates a database ofcollective player communications to help improve game-wide, player-wide,and other global averages and metrics, as described herein.

Referring back to FIG. 13A, in block 1315, the system analyzes commandsinput by the player and any results therefrom. For example, if theplayer frequently uses emote commands, then the system would providepoints or weighting to the role playing characteristics for that player.If the player has numerous commands for buying and selling items, thenthe system may provide points or weighting to the player indicating theplayer is trying to trade or engage in commerce.

Referring to FIG. 13D, an example of a subroutine 1315 to analyzecommands and results begins in block 1362 where the system receives userinput. As described herein, the input can include combat commands,emotes, spell use, equipment use, bartering transactions, or other userinput. In block 1364, the system receives feedback from the game basedon the user input (although block 1364 may be performed later in thesubroutine). After receiving the user input and any game feedback, thesystem employs one or more of the processes described herein to analyzethe received data; however, some of the processes described herein maybe optional, and additional processes for analyzing the data are ofcourse possible.

In block 1366, the system can analyze any combat commands. For example,the system can determine where the user strikes an opponent, with whatweapon, and how often. Alternatively or additionally, the system cananalyze spells cast or abilities used during combat, their sequence, andso forth. Certain players may perform certain actions for differentresults. For example, some players may prefer a more comedic style ofcombat, and may push an opponent over a cliff, cast ineffective spellsthat result in some comedic effect, and so forth. The system can thenflag or weight the player accordingly, as noted above.

In block 1368, the system analyzes any emotes or other commands input bythe user. For example, as noted above, a player who uses emotes with afrequency and/or variety exceeding a certain threshold may be classifiedas a role-player. The system can even analyze the type of emotes used todetermine a characteristic for the player. For example, a player whofrequently bows may further represent a role-player, whereas a playerwho uses aggressive emotes may be characterized as aggressive and shouldnot be matched with children or other players who could be offended.Another example is commands input may be command to barter for digitalitems within a game, and the player's frequency of bartering,effectiveness in bartering, and so forth. For example, in someembodiments the system maintains a database or other table of averagevalues or trading values of a plurality of digital objects. Userstrading, selling, or otherwise exchanging digital objects for valuesexceeding their average values may be weighted as more skilled thanusers accepting less. The system can then flag or weight the playeraccordingly, as noted above.

In block 1370, the system can analyze combat effectiveness for theplayer. For example, certain spells, in a certain order, can have agreater affect in defeating an opponent than others. The system cananalyze damage inflicted per second by a player of a given level versusan average for players of that level (and possibly of that same class orin a specific encounter or against a specific opponent) to determinewhether the current player is more effective than others. For example,if the player is able to target a weakness of an opponent, use spellsthat produce more damage of an opponent, and so forth, the system canflag the player as more effective than others. Under block 1370, thesystem can also gather additional data, such as number of opponentsdefeated per unit of time (e.g. per hour). The system may normalize sucha metric based on the player's level or total level of the party, ornormalized based on the combined hit points or level of the opponents.Obviously, more effective players can defeat stronger and greaternumbers of opponents than less effective players, and thus the systemcan flag or weight such players accordingly.

In block 1372, the system analyzes spells cast by the player, equipmentused by the player, and so forth. For example, the system can analyzewhat healing spell a player may cast, and when, to determine howeffective a healing-class player is. If a player were to cast a powerfulhealing spell, but when fellow players in the party have not sufferedmuch damage, the player has “wasted” much of the spell by over-healing(not efficient use of mana), and thus the system tracks use of certainattributes such as mana efficiency or usage and can flag the player asless sophisticated/experienced (despite whatever level the character maybe). Likewise, the system can determine whether the player frequentlychanges equipment (weapons, armor, rings/amulets, etc.). Such a playermay be an optimizer and the system may flag or weight that playeraccordingly, and fellow players may wish to play with fellow optimizers(or be annoyed by such players, and may not wish to play with such aplayer). Alternatively or additionally, the system can analyze the inputcombat commands to determine the player's aggressive (“aggro”)effectiveness.

In block 1374, the system updates the database of collective playercommands to help improve game-wide, player-wide, and other globalaverages and metrics, as described herein.

Referring back to FIG. 13A, in block 1320, the system compares theanalyzed data to any player-provided preferences. For example, if theplayer provided input indicating that he is a quester, and the dataanalyzed under blocks 1305 through 1315 agree with this assessment, thenthe system assigns a high confidence value to its characterization ofthe player as a quester, and stores such a determination. However, ifthe player indicates that he is an quester, but the gathered dataconflicts with this self-assessment and finds the player to be more of apower-gamer, then the system would in some cases provide a higherpercentage or weighting to the power-gamer characterization, with alower, but still relatively high, characterization for questing. As anexample, the player may be characterized as 65% power-gamer, 35%quester, and thus the system would attempt to find similar players withsuch a makeup. Indeed, the system may attempt to identify players thatself-describe themselves as questers, but whose gameplay reflect apower-gamer. Thus, the system can have a higher confidence in matchinglike players who have similar self-described characteristics, as well assimilar gameplay characteristics.

In block 1325, the system develops rankings of characterizations forplayers and stores such data. Thus, in the example above, the systemdetermines that the player is 65% preference for power-gaming and 35%preference for questing, and thus stores such characterizations with thedata structure for that player. Additionally, the system may storepreference information and/or rankings related to different games, gear,chat, skill by class, efficiency, and so on.

An example of a data structure or table for storing certain data fromplayers is shown in Table 4 below. The data structure or table may bestored with the player's profile noted above. The system may continuallymodify or update this data structure or table as the player plays gamesor undertakes other online endeavors, and the system uses such a datastructure/table for matching, as described herein.

TABLE 4 Metric/Characteristic Values PlayerID GameID CharacterID Averagemovement/game session Zone counts Average time spent within azone/session Frequency of communications Duration of communicationsAverage sentence length Average number of spelling/grammar errorsGrammars/vocabularies used Player counts for other players communicatedwith Emotes used/session Digital object trades/session Combateffectiveness Healing effectiveness Spell use effectiveness Equipmentuse effectiveness Equipment adjustment/session Opponents defeated/hourDamage produced/seconds Aggro effectiveness Critical hits/battle Goldacquired/session Experience points gained/session Damageinflicted/session Other characters count Number of alternativecharacters Number of players interacted with/session . . . Watts/HourKilowattRating AvgPlayTimes AvgPlayDuration Crafter weight/percentageGrinder weight/percentage Explorer weight/percentage Role-playerweight/percentage Quester weight/percentage Twinker weight/percentageTrader weight/percentage . . .

As shown above, only some of the metrics described herein are shown inTable 4. For example, the data structure or table can includeinformation regarding preferred servers or shards that the playertypically joins for a given game, energy/power/mana used perencounter/gaming session/hour, etc. While each player is generallydescribed herein as being associated with a particular type (or blend oftypes), the system can also accommodate more complex players who enjoyacting as different types depending upon a given game or character, andthus the various tables/data structures can include further partitioningor granularity of the data to account for this. For example, when theplayer is playing a warrior in one game, the player may prefer to act asan explorer, whereas when the player is playing a wizard in anothergame, the player may prefer to act as a role player.

The data structure/table of Table 4 can include many other metrics, orinclude fewer metrics. Further, a user may have multiple profilesassociated with different user IDs, games, or activities each withdifferent characters and associated statistics. As shown above, anoverall metric of a player's effectiveness can be represented by goldgained per session, experience points gained per session, damage dealtto opponents per session, and/or other metrics. A grinder wouldtypically have higher experience points per session and/or higher damagedealt per session, and likely also higher than average gold obtained persession. However, a player with a high gold gained per session withassociated commands indicating trades could represent a player who likesto optimize his character or otherwise trade (e.g. a trader's). Whilemost metrics are shown above as being dependant on or compared to agiven gaming session, other comparators may be employed, such as beingdependent on the party, on a particular level of character, on allplayers within the game, and so forth. In other words, the system cannormalize metrics based on a variety of factors. Further, the system cannormalize metrics based on equipment weightings (described herein).

The “other characters count” may represent a count of other charactersthat the player wishes to play with in any given session or have in hisparty. In other words, this can represent a “bonding metric”, andindicate whether or not the player wishes to play with numerous fellowplayers, or have only a party of close friends when playing. Further,“number of players interacted with per gaming session” can representanother “bonding metric”, to indicate how social the player is in thegame.

“Number of alternative characters” can represent a player who, ratherthan focusing on a single character, has multiple alternativecharacters, and enjoys playing each of these different characters,rather than optimizing any single one of them. Such players may wish toplay with other players who also like to frequently use alternativecharacters.

The grinder, explorer, role-player, questor, twink, etc. fields canrepresent weights or percentages for how the system interprets theplayer as behaving. As noted herein, some players may always act as agrinder, and have a 100% value for that field; however, other playerslikely have a mix where they might be 60% explorer, 30% role-player, and10% questor. The system can then attempt to find players with a similarbreakdown or otherwise determined complementary criteria orcharacteristics, which can lead to harmonious game playing betweenplayers.

Automatically Identifying New Games/Quests for Players

In some embodiments, the system collects, aggregates, processes, andanalyzes information about users and users engaging in networkedactivities to match users to other users and/or determines correlations(positive and/or negative) between users, for example as furtherdescribed herein and in FIG. 15. Based at least in part on some or allof the information gathered, the system suggests or discourages variousactivities, relationships, or other items which may or may not be ofinterest to the user. Referring to FIG. 14A, an example of a routine1400 for identifying new games, sessions, quests or other onlineendeavors in which players can share an experience is shown. In thismanner, the system can tailor the game play to the player's preferencesand/or style. For example, if a player is known as an explorer, thesystem can identify quests that will cause the player to explore newlands or undiscovered territory. As another example, if a player isknown as a grinder, the system can, for example, offering quests orother incentives, or direct the player to better grinder areas and offerrewards for defeating monsters in those areas. Furthermore, the systemmay identify players who have not logged in for a threshold period oftime and incentivize their return to the game by offering those playersa significant reward for returning to the game and completing aparticular game interaction. The game interaction could be tailored to aplayer or group of players who have not played for awhile in order tobring the players back to the game and also possibly introduce them tonew players. For example, an explorer may be enticed by the opportunityto explore a new map and be rewarded with access to a new map with agroup of similar or like-minded players or some ability that makesexploring more enjoyable. In this manner, players are incentivized toreturn to the game with the opportunity to play the game in a mannerthat they are likely to find enjoyable and with other players that arelikely to enrich their experiences.

Beginning in block 1405, the system identifies a new game, session,quest, or other shared endeavor, which may be of interest to the user.For example, such as identifying a pending game which requiresadditional players or in which a player has dropped out and needsanother player, or the system initiates a new quest or session within agame, etc. Alternatively or additionally, the system can launch a newgame or new expansion portion of a game, in which to populate it withnew or migrated characters as described herein. Alternatively, thesystem may receive a selection of a game or shared endeavor from a userand identify players based on the selection. For example, the system maydisplay to a player a list of available quests or other endeavors thatcan be completed. Upon receiving a selection of a quest from a player,the system may identify other players who may provide a good match forthe player based on skill level, style of play, character attributes,and so on. In some cases the other players may be playing the same gameas the player or may be playing a different game or may be offline. Oncethe system has identified matching players, the system can notify any orall of the players of the opportunity to complete the selected quest.Alternatively, the system may send the player who selected the quest alist of matching players and allow the player to select the players withwhom the player would like to complete the quest. Upon receiving theselection of players, the system may notify those players of theopportunity to complete the quest with the player(s) with, for examplean invitation to join a party to complete the quest. In someembodiments, the system determines a negative correlation between a userand a given activity, item, or relationship. For example, the system mayidentify a game likely of little interest to the user, a quest of a typenot suited to the player's classification, an item that does notcomplement the players existing equipment, one or more other playerswhose play style or other criteria or characteristics might be lesssuited or undesirable to the user, etc. Based at least in part on thenegative correlation determined, the system discourages, does notsuggest or make available, provides disincentives, and/or otherwisereduces the likelihood that the user encounters, experiences, or engagesin the activity, item, or relationship.

In block 1410, the system matches players based on storedcharacterizations. Details regarding such matching are described hereinand, for example, with respect to FIG. 15.

In block 1415, the system sends one or more communications to a playeridentified under block 1410. The player may have indicated a rankordering of communication methods, such as:

1. In-game text communication;

2. E-mail;

3. SMS/MMS message;

4. Voice message.

In some embodiments, the system may call or send a message to an offlineplayer indicating that a suitable match, for example a match exceeding athreshold and/or other positive correlation, has been found or is likelyto be found at a particular time. In this manner, the player need notwait online for an adequate match to be found. Such a message canindicate when the new session is to begin, and provides some informationregarding the new session, such as which of the player's characters isbest suited for the endeavor, who else may be joining, and so forth. Themessage can also indicate the confidence level as to how enjoyable thegameplay may be for the player based on how close of a match the systemhas generated. For example, in some embodiments, the system quantifiesthe positive correlation of a match as a percentage and provides anindicium of the percentage to the user. In other embodiments, the systemprovides additional information including factors used to determine thepositive correlation or match such as play style, user characteristicsand criteria, equipment information, shared activity information such asrelated quests, play times, and other classification data andinformation. In some embodiments, the system displays one or more of thecriteria used to determine the match and receives feedback such as anindication from the user regarding preferences for which criteria aremore desirable and which are less desirable or important in determiningthe match. Users effectively train the system or provide informationused to create a profile that assists in determining positive andnegative user correlations. Different users, therefore can havedifferent matching profiles as maintained by the system and determinedaccording to the user preference indications provided. Additionally,different preference information and user preference profiles aremaintained in some embodiments for different networked activities,characters, etc. Before sending the communication, the system in block1415 (or 1410) determines whether the new endeavor is to occur duringthe player's preferred play time.

Under block 1420, the system determines whether it has received aresponse from the player, for example within a particular time period orthreshold, and if not, identifies another player to match under block1425 and then loops back to block 1415. As noted herein, the systemattempts to match players that are appropriate for thegame/quest/endeavor. If a response has been received, the systemdetermines under block 1430 whether enough players have respondedaffirmatively to joining the new endeavor. If not, the process loopsback to block 1425. If enough players have been assembled, then thesystem initiates the game/quest/endeavor under block 1435. Under theroutine 1400, players can receive messages and look forward tosubstantially immediately joining a new endeavor without having to waitin any queue.

Conserving System Resources

Data centers consume heavy amounts of power, particularly the serversdescribed herein. However, many servers may not be active, or may haveonly relatively few players on such servers, but the servers arenevertheless powered up because they represent individual virtualworlds, or are waiting for peak loads which occur only periodicallyduring the day or week. By identifying user power-relatedcharacteristics as described herein, the system, based at least in parton the user power-related characteristics and/or power-related criteria,performs various actions such as migrating users between servers;providing incentives or disincentives for users to engage in variousactivities at certain times or under certain conditions; adding,removing, powering up, or powering down activity-related hardware and/orsoftware; and other actions designed to improve power and hardwareefficiencies. In some embodiments, users are identified according topower-related characteristics and associated with one or more groups.These groups are associated with power-related characteristicsthemselves, for example, an average electrical load at a given time oran electrical load profile over a given time period such as a day, andbased on these group characteristics, the system, with respect to theentire group, performs the various actions described herein designed toimprove power and hardware efficiencies. Users have individualcharacteristics and classifications used for matching purposes and otherpurposes as described herein whereby the user is viewed and treated moreas an individual as well as power-related characteristics whereby theuser is viewed and treated less as an individual and more as a consumeror as a unit of power generally. Thus, in some embodiments as furtherdescribed herein, the system identifies a first user and at least afirst power-related characteristic associated with the first user. Basedat least in part on the first power-related characteristic, the systemperforms one or more actions. For example, the power-relatedcharacteristic may include an average unit of power consumed by the userduring a specific time period and the system performs an action such asproviding the user an incentive to engage in a networked activity duringthe specific time period or during a different time period. The systemalso identifies a second user and at least a second power-relatedcharacteristic associated with the second user. Based at least in parton the first power-related characteristic and the second power-relatedcharacteristic, the system performs one or more actions. For example,the system may determine, based at least in part on the first and secondcharacteristics, that a unit of power consumed by the first and seconduser together during a certain time period is likely to exceed a certainthreshold and provide an incentive or disincentive for the first andsecond user not to both engage in one or more networked activitiesduring the certain time period.

For example, referring to FIG. 14B, within a given time zone, a peakload on the servers can be at about 10:00 p.m., with a sharp riseoccurring at 7:00 p.m., and a large drop off occurring after 1:00 a.m.As described herein, the system can begin shutting down one or moreservers and migrate players to other servers after 1:00, to therebyconserve resources; likewise, the system can predict that more serversmust begin to be powered up at around 7:00 p.m. to prepare for the 10:00p.m. peak. Conserved resources include not only reduced energyconsumption, but also reduced wear and tear on servers, data storagedevices, and other network resources, thereby reducing a number ofservers or other network elements that could crash and need to bescrapped/recycled.

Referring to FIG. 14C, an example of a routine 1450 to conserveresources begins in block 1455 where the system analyzes player profilesand determines a typical playtime for players, and in block 1460,analyzes logs of server and other network resource consumption. In block1465, the system not only determines the peak usage (typically from thedata under block 1460), but also determines from player usage whichplayers have been playing continuously up to the peak, versus playerswho have joined at the peak and will be playing thereafter. The systemthen, under block 1465, allocates resources to place players whohistorically play from 10:00 p.m. past 1:00 a.m. on servers that willremain powered on past the peak. The system also, in some embodiments,powers down unused servers past the peak. Further, the system mayidentify certain servers to handle certain types of players. Forexample, role-players, “chatty” players, and other players who mayconsume lots of network traffic exchanging communications may be movedto one or more servers and certain network equipment that can handle alarge amount of traffic, whereas other players who may consume servercycles, but not as many other network resources, would be allocated toone or more different servers.

Likewise, the system can analyze players who play well together, andaggregate those players on a particular server. For example, among10,000,000 players of a given game, the system can identify 20,000players who play well together, and move those players to particularservers, since they may be playing at particular times. Those serverswould also be powered off or operated at reduced loads, etc. when thoseplayers typically do not play. (The system, of course, must take intoaccount different time zones, as well as holidays, daylight savingschanges, and so forth.) The system works to find servers that may have alow number of players (e.g. under 1,000) and move those players to ahigher use server (e.g. a server with approximately 10,000 players).

In block 1470, the system can determine incentives to provide to playersto conserve resources. For example, the system may help provide certainincentives to players to reduce the peak load, while not impacting tooseverely the player's enjoyment of the game. The system may providecertain quests that would be available only during certain off-peak timeperiods, provide use of certain digital objects during off-peak hours,suggest game play between players (possibly even an additional new zone)during off-peak hours under the player matching described herein, and soforth. Of course, the system can likewise provide disincentives forplayers, such as higher charges, reduced experience, fewer quests, areduced set of services, etc. during peak hours.

In block 1475, the system distributes these incentives to players. Forexample, the system can provide messages during a game to encourageplayers to drop out of a game as the peak load approaches. Alternativelyor additionally, the system can send an e-mail, voice mail, textmessage, or other communication, in a manner similar to that describedherein for matching players.

Of course, the system can perform further optimization to conserveresources, beyond that which is described above. The system may offer aselection of servers or shards for the user to join at the beginning ofa gaming experience, but actually assign the user to a different serverdepending upon system resources and a desire to conserve power. Forexample, the user may select to join the “red” server, but the systemmay actually log the user into the “blue” server because the red serveris currently in standby state or to be powered down. Furthermore, thesystem may switch the user from the red to the blue server during gameplay to conserve energy or other resources, as noted herein.

Moreover, the system can determine additional incentives, beyond theexamples provided herein. The system could provide tiered pricing basedon the number of hours per week, the number of units of energy used permonth, and so forth. The user could be provided incentives to drop off agame, to move to another server, etc., to thereby allow the given serverto be put into standby mode, powered down, etc. According to someembodiments, the system may also only make available certain of a user'scharacters based at least in part on power-related criteria. Forexample, the system may determine that a first user character on a firstserver is associated with a first power-related characteristic orcriteria and, based at least in part on the first characteristic, apower-related threshold is likely to be exceed on the first server ifthe user engages in a first networked activity with the first usercharacter at a specific time. The system may therefore during thespecific time prohibit the user from playing the first user character,provide incentives or disincentives (such as increased/decreasedexperience, special quests, monetary rewards, faster group matching orqueuing for activities, etc.) for playing the first character or forplaying a second character having a second power-related characteristicwhereby if the user engaged in a networked activity (such as the firstnetworked activity or a different networked activity) with the secondcharacter, a power-related threshold would not be exceeded.

Suitable Player Matching

The system helps foster community by analyzing user behavior,characterizing users from the analysis, and then aggregating orotherwise grouping users together based on positive or negativecorrelations determined. The system can match a given player to anothersimilar player, a given player with a group of similar players, orgroups of similar players together. Thus, the system can identify aplayer or group of players from the database, identify certain criteria,such as core criteria, for him/them, identify player characteristics,and determine positive and negative correlations, such as likely matchesor lack of compatibility, among players. The system may also optionallydetermine an equipment hash, or store matches, as well as any otherfunctions described herein.

For example, the system may have analyzed a player and noticed that theplayer likes to move around multiple zones within a virtual world, andthus the system has characterized that player as an explorer. Therefore,the system can match that player with fellow players who are explorersand like to move about and explore the virtual world. Alternatively, thesystem may have analyzed the player's communications and determine thatthe player is most accurately characterized as a role-player, and thusthe system matches that player with fellow role players. Indeed, asdescribed herein, the system may even segregate such like players tocommon servers or shards so that only players that share thosecharacteristics play together.

The system includes the following: identifying a first player; trackingor recording a first set of activity information, actions, behaviors, orother data associated with the first player; storing the first set ofinformation, actions, behaviors, or other data; analyzing the storedfirst set of information, and based on the information, classifying orcategorizing the first player as at least a first type of player; andthen, based on the identified or classified first type, determiningcertain criteria from the first set of information to match the playerto one or more other players sharing the first type. The system alsoidentifies negative correlations based on the information between theplayer and other players as further described herein. Thus, in someembodiments, the system matches or otherwise groups or associates orperforms actions related to users based on similar characteristicsshared between users, for example positive correlations exceeding orbelow a given threshold based at least in part on the usercharacteristics, preferences expressed by users related to thecharacteristics, etc. and/or also based on different and dissimilarcharacteristics of the users, for example negative correlationsexceeding or below a given threshold based at least in part on the usercharacteristics, preferences expressed by users related to thecharacteristics, etc.

Furthermore, the system includes the following: identifying a secondplayer; tracking or recording a second set of activity information,actions, behaviors, or other data associated with the second player;storing the second set of information, actions, behaviors, or otherdata; analyzing the stored second set of information, and based on theinformation, classifying or categorizing the second player as at least asecond type of player; and then, based on the identified or classifiedsecond type, determining certain criteria from the second set ofinformation to match the second player to one or more players sharingthe second type, wherein at least one of the certain criteria in thesecond set is a different criteria from the criteria used to match inthe first set of information.

Thus the system is configured to match different types of players usingdifferent information depending on the type of player. For example,along with a number of common characteristics among all types ofplayers, the system can associate greater weight on level, similarity ofequipment/gear, playing skill, and the like when matching power gamers.Conversely, when matching role players, the system can associate lessweight to these factors and look more closely at types of activitiesthey engage in, their chat characteristics, their play times, etc.

Furthermore, the system can employ different matching algorithms fordifferent types of players. For example, the system can first identify aplayer of a first type. Then the system can apply a selected orappropriate matching algorithm to the first type of player based on thattype. In the case of multi-typed players (such as a player who is 40% ofthe first type, and 60% of the second type), the system may use a numberof different matching algorithms based on type, with appropriateweighting.

An example of a player matching subroutine 1505 is shown in FIG. 15.Referring to FIG. 15, the subroutine 1410 begins in block 1505 where thesystem identifies a player from the database of profile/player datastructures. While individual players may be selected, alternatively oradditionally, players may be grouped by the system, or players may havechosen to always play together, but may wish to have additional membersjoin. For example, the system may find players that often explore theworld independently and attempt to match them with players or groupshaving a similar or complementary play style and/or skill level. Thus,the system can match one player with another player with a similar orcomplementary play style, one player to a group of players who may enjoyplaying together, or similar groups together.

Under block 1510, the system matches additional criteria, such as corecriteria. For example, the system may determine that the player is aminor (under the age of 18), and thus looks to match that player withfellow minors. In another example, the system determines that the playerfrequently uses profanity in chat, and therefore, the system matchesthat player with other players who use profanity. In some embodiments, aplayer may be able to specify which certain core criteria they wishedthe matching system described herein to employ so as to allow them toamplify their own experience (e.g., language requirements so that theplayer can communicate with other players, or location requirements sothat the player is in the same time zone or shares similar pop cultureor geopolitical references), as well as identify exclusions or certaincriteria the player wishes to highlight and avoid making matches withother players. Under block 1510, the system attempts to make an initialmatch of the selected player to a group or categorization of playersthat have initial core characteristics, whereby a mismatch of such corecharacteristics could lead to a less than enjoyable gaming experience, avery upset player, or even a lawsuit.

Under block 1515, the system matches player characterization data. Suchplayer characterization data can include, the relative weights betweenthe types of gameplay (power-gamer versus quester), as well as someother less definitive or more subjective data described herein. Thesystem may, for example, determine how much experience the playergenerally gathers on average per session, such as a level adjustedexperience points per hour value. If this value conflicts with anexperience points per hour for other players, then a match with theseother players might not lead to an enjoyable gaming experience for theparticular player because the other players prefer “grinding” to quicklyraise their levels or because the other players are more proficient.Under block 1520, the system determines an equipment rating or hash, andwhether such equipment hash provides a rough match with other players.For example, if the particular player matches the core criteria andmatches player characterizations, but is to be put in a group withwell-equipped players having high equipment hash values and theparticular player has a low equipment hash, then the particular playermay not have a good gaming experience because he may be killed ordefeated easily in a game, as compared to other players who have highequipment hashes. Further details regarding computing the equipment hashare described herein with respect to FIG. 16.

In block 1525, the system confirms the match by analyzing othercharacteristics, such as those within the group previously created, orwith a player previously identified and who may have been looking foranother player to play with. If matching within a group, the system canperform statistical analysis of all statistics among the characters inthe group, and compare that with the character for the player to see ifthe characters align, even if the player characteristics align. Forexample, the particular player may provide a good match with otherplayers, but their characters may provide a mismatch (e.g., are toocommon, and thus would not lead to a well-rounded or balanced party, asnoted herein). The confirmation can also check other factors, such asfaith, sexual preference, and so forth. The system in block 1525 helpsprovide an increased confidence that a match will be successful, and mayassociate a weighting or probability the match.

As noted above, the system can match individual players together so thata plurality of geographically separated players may work together with agiven online endeavor, game or virtual world. However, the system canalso aggregate like players into groups. For example, under optionalblock 1530, the system associates the player with the matched collectionof players, and thus the system helps build associations of similar orlike-minded players or identify alternative play options for a player.The players may, for example, choose to create a group or clan and playa game together or may choose to play alone or with a different group ofpeople. In block 1535, the system determines whether there are otherplayers in the database to match, and if so loops back to block 1505.While described herein as matching players, the system can providegreater granularity and match characters of players. Thus, theparticular player may be matched with other players, and the system mayfurther provide matches between the particular player's characters andthe characters of other players in that group.

In some embodiments, the system may identify matches for a particularcharacter and notify the player of these matches even if the player iscurrently using a different character or playing a different game. Forexample, a user may be playing a first game with a first character andthe system determines that the user's performance with the firstcharacter is below (or exceeds) a particular threshold such as a lack ofexperience gained, a lack of movement for a specific time period, someindication of boredom or lack of efficiency, etc. The system thennotifies the user of a match or other opportunity (undertaking a quest,etc.) for a second character associated with the user in the first gameor in a second game. Thus, the user's time might be spent moreproductively or enjoyably by playing the second character instead of thefirst character. As another example, a user may require a certain set ofconditions to be fulfilled or criteria to be satisfied beforeundertaking an endeavor or performing an action with a first character.For example, a user might need a certain group or group composition, bewaiting for certain friends to be online playing specific characters,require a certain opponent to be present, etc. While the conditions orcriteria are not satisfied, the user may elect to play a secondcharacter and have the system inform them when the conditions aresatisfied or other events occur. They could then return to playing thefirst character instead of the second character when conditions arefavorable or otherwise desirable. As another example, a player may havetwo characters for a particular game, a level 40 healer, a level 10healer, and a level 25 tank. While the player is playing the game as thelevel 40 healer, the system may find a matching group looking for a tankwith similar characteristics to the player's level 25 tank. The systemcan then notify the player and allow the player to exit the game withthe level 40 healer and join up with the matching group using the level25 tank. Additionally, the system may identify matches for differentcharacters regardless of a player's online status and regardless ofwhich game the player is playing.

For example, if a player is playing a fantasy-themed game and the systemidentifies a player, group of players, character, or group of charactersthat may be a good match for the player and/or one of the player'scharacters in a pirate-themed game based on skill, style, location,interests, etc., the system may notify the player of the match andprompt the player to switch to the pirate-themed game. Furthermore, thesystem may recommend games to a player that the player does not own ormay have never played including newly launched or newly available games.For example, if the system identifies the player as a DPS and a grinder,the system may recommend games that promote, specialize, or focus onthis combination of styles of play. As another example, if a player isconsistently underperforming in one game because the game does not suitthe player's play style, the system may recommend another game that maybe a better fit for the player's style.

Determining Equipment Values

Referring to FIG. 16, a subroutine 1520 for determining equipment hashvalues begins in block 1605 where the system determines whether the itemhas a predetermined weighting. For example, some games may associate alevel or point value to each digital object or equipment item, despitethe fact that the item may have multiple properties (e.g., boost one ormore statistics, increase one or more resistances to damage, etc.). Ifnot, then the system in block 1610 determines a weightingalgorithmically. Such an algorithmically determined weighting canconvert percentages to normalized integers (30% or 50% to 3% or 5%), andadd such values to other values for the item. For example, certain itemsmay be assigned corresponding values based on the properties theyprovide. If leather armor provides an armor class of 2, chain mail anarmor class of 4, and plate mail an armor class of 6, then leather,chain or plate armor would have values of 2, 4 or 6 respectively. Thesebase values may then be increased if the items have particular specialcharacteristics. For example, if a particular item of armor confersresistance to a particular type of attack, the base value might beincreased by 1 or 2 to account for the greater power of the item.Furthermore, base values for items may be increased if equippedsimultaneously, such as a leather helmet, leather armor, leather shield,and leather boots.

In block 1615, the system may simply add the item weightings. Underblock 1620, the system determines whether there are more items toconsider. Under the subroutine 1520, the system computes a combinedtotal equipment weighting or hash for all items in a character'sinventory. Thus, under the subroutine 1520, the system determines orcomputes a single number to reflect the entire inventory of digitalobjects possessed by each character. Under block 1625, the systemperforms any post-processing necessary, such as normalizing data ifcharacters are moved between the virtual worlds that use differentvalues for equipment. Other post-processing can include encryptingvalues, compressing information, and so forth.

Pre-Qualified Virtual World Play

In some embodiments, the system may also provide pre-qualified virtualworlds. Pre-qualified virtual worlds allow world access, entry, and/ortransfers not based on preference or payment, but on usercharacteristics, criteria, and/or classifications described herein, forexample based on performance metrics, play styles, play times, etc.Thus, based on a player's actual performance, classification, and/orother quantifiable criteria or other information described herein, thesystem determines whether a player is qualified to move to anotherinstance of the virtual world. For example, one instance of apre-qualified virtual world may allow characters to enter if they haveachieved a certain level or number of experience points while anotherinstance of a pre-qualified virtual world allows characters to enter ifthe system has, based on an analysis of their gaming interactions,deemed the characters to be used primarily as explorers. As anotherexample, one pre-qualified virtual world may allow characters to enterif they have proven to be highly proficient in at least one characterattribute, such as characters that tend to maximize the use of theirhealing spells or some other ability. In this manner, althoughcharacters in the world may be diverse in terms of play style andattributes, players know that characters they meet in the world will behighly skilled in at least one particular area relative to game play.

In some embodiments, the system allocates specific electronic games,virtual worlds or other online endeavors based on characterized userbehavior. Thus, the system determines one or more characteristics of theuser by analyzing user behavior within an electronic game/world/onlineendeavor and compares the analyzed behavior to predetermined parametersassociated with multiple characteristics, as noted herein. Based on thedetermined characteristic, the system can pre-qualify or authorize theuser to access a new game/world/endeavor/activity specificallyestablished for users who all share that same characteristic or who haveother characteristics that satisfy certain criteria or thresholdsrequired for access to the new game/world/endeavor/activity. The systemcan then send a communication or other indicia to the user offering theuser to join the new game/world/endeavor/activity. For example, thesystem might identify a player whose criteria or classification or otherinformation or characteristics are determined to provide an advantage orto be otherwise desirable in a given virtual world or for the player toparticipate in a given networked activity. For example, some users aremore helpful to other users and often act as guides or mentors. In othercases, a world might need characters of a certain class for balancepurposes. Or the world might need the player to satisfy certain othercriteria. Based at least in part on this determination, the systemprovides access to the world or invites the user to participate in theactivity. In some embodiments, the system provides incentives for theuser to play in a particular pre-qualified world or engage in aparticular networked activity such as by providing free play, increasedexperience or advancement bonuses, starting the user at a higher levelor more advanced or powerful position, etc.

As a result, the system can establish separate servers or shardsassociated with particular types of players who share a similar playstyle or have other desirable (though not necessarily similar)associations together, which can help enrich the gaming experience forthose players. As one example, players who are characterized asrole-players may more often like to interact with fellow role-players,and thus a separate server/shard may be established on which all playerscharacterized as role-players would be pre-qualified or assigned, andother types of players would not have access to that server/shard.Likewise, players who have a high “bonding metric” or players who tendto interact with only a close circle of the same fellow players couldlikewise be aggregated on servers that have been established primarilyfor such players.

Generally, as characters are moved from one virtual world to anothervirtual world, including pre-qualified virtual worlds, they would movewith items and gold intact since the world qualification system wouldtake such unbalancing effects into account. Players could start in asingle generic world or begin elsewhere based on prior play in one ormore games or based on player characteristics described herein. Then,based on a variety of criteria, they would gain points or otherassessment characteristics that would potentially allow them to qualifyfor transfer to one or more other virtual worlds, which had players whoplayed similarly to themselves or who had other qualifyingcharacteristics. The system can apply tiers of matching players to helpfurther consolidate common players together. Pre-qualified virtualworlds could be used to group so-called power gamers, role-players, orother similar type players on similar servers. Pre-qualified virtualworlds could also be used conversely to create more diverse or balancedservers. In this latter case, the system might qualify more tanks,healers, tradesmen, races, factions, or other avatars to create anoptimized playing environment. By consolidating like players on one ormore common servers, the system can help further conserve resources, asdescribed herein.

The different world instances might have slightly different or entirelydifferent content. There could be more characteristic-specific contentbased on the types of avatars transferring to the world (e.g., more raidcontent for higher level raiders, more quests or lands for explorers,more solo content for solo players, etc.). In this manner, thepre-qualified virtual world can be configured to present opportunitiesto the players that will further enrich their gaming experience. Thesystem identifies a first player and determines one or morecharacteristics associated with the first player. Based at least in parton one or more of the first player characteristics, the system providesaccess to a first networked activity, such as a pre-qualified virtualworld. In some embodiments, the system further identifies a secondplayer and determines one or more characteristics associated with thesecond player. Based at least in part on one or more of the secondplayer characteristics, the system does not provide access to the firstnetworked activity. In some embodiments, based at least in part on oneor more of the second player characteristics, the system provides accessto a second networked activity. For example, the system can analyze theplayer's profile to determine the type of gamer the player is, and thenmatch that player with a virtual world more appropriate (and thus moreenjoyable) for the player. For example, if the player's profileindicates he is a grinder, then the system will recommend (or simplyplace) the player in a new virtual world that appeals to grinders.Likewise, the system can provide virtual worlds with more raid contentfor higher level raiders, virtual worlds with more quests or lands toexplore for explorers/questers, virtual worlds with more solo contentfor solo players, and so forth, as described above.

Referring to FIG. 17A, the system performs a routine 1700 to determinewhether a player is pre-qualified. In block 1702, the system may providea generic virtual world, or the virtual world, generic or not, may beprovided by a third party. Under block 1704, the system analyzes theplayer's performance within the virtual world. Alternatively oradditionally, the system analyzes the player's profile described above,to access a player's performance within one or more games.

In block 1706, the system determines whether the player has satisfied agiven threshold. As noted above, this threshold can be whether theplayer has achieved a certain level or number of experience points orbased on other player criteria or characteristics as further describedherein. The system can establish certain thresholds that must be met fora player to be authorized to access certain pre-qualifiedservers/worlds. The thresholds could be based on certain criteria storedin the player's profile. For example, if a player is characterized as apower gamer, the player must also have established a certain level ofskill as a power gamer, and thus the system can analyze equipmentmetrics, character level, zones played, manna efficiency, experiencegained efficiency, and other metrics against preset thresholds formore-skilled power gamers (an “elite-level” of power gamers). As aresult, a separate server/virtual world can be established forpower-gamer-style players who have a quantifiable level of skill overfellow power gamers, and thus may prefer to play with equally skilledpower gamers, rather than with inexperienced players. Additionalperformance-based virtual worlds are contemplated and the systemprovides a plurality of worlds comprising a hierarchy or “ladder” ofvarious performance levels.

The system may also, under block 1708, determine whether the player hassatisfied a second, alternative threshold, such as whether the playerhas proven to be highly proficient in at least one character attribute,such as combat effectiveness or ability to maximize use of healingspells. If the answer to either of the threshold inquiries isaffirmative, then the player is offered, under block 1710 theopportunity to enter a pre-qualified virtual world. The offer may be inthe form of an in-game message, or an out-of-game message, such ase-mail, SMS/text message, or other communication described herein.

Rather than providing two alternative thresholds, the system may employa single threshold, or two or more thresholds, all of which must be metbefore the player is pre-qualified to enter or otherwise access thevirtual world. For example, the player may not only need to haveacquired a given level, but also proven to be proficient or have apropensity to play as an explorer. Thus, the virtual world to which theplayer is recommended under block 1710 may be a virtual world thatappeals to players of a minimum threshold of competency, and have acommon play-style. This can result in a more pleasing game experienceamong such pre-qualified players within the new virtual world.

FIG. 17B shows a routine 1720 for allowing players to move to a virtualworld, even temporarily, without losing experience, equipment or otherstatistics. The routine 1720 begins in block 1722 where the systemreceives a request from a player or otherwise identifies a player tohave that player's character join a virtual world in which thatcharacter has not previously played. Such a “foreign” charactertypically may have gathered experience, equipment, and other enhancedstatistics or abilities in another virtual world (e.g., the genericvirtual world), and the player wishes to import this character intoanother virtual world. In block 1724, the system determines whether theplayer or character is pre-qualified. During such qualification check,the system can first determine whether the player is authorized to playwithin the virtual world. Some players may have failed to meet the abovethresholds, or may be blacklisted or banned from certain virtual worldsbecause of misbehavior, failure to pay the monthly fee, and so forth.Alternatively or additionally, the character may simply be inappropriatefor the virtual world, such as a fantasy-based character requesting tobe used in a science-fiction game (or the system may offer atransformation of the player's character into one appropriate for thenew game as further described herein). As another example, qualificationmay require that the player pay a fee (real or virtual currency) forentering or accessing the virtual word. For example, certain virtualworlds may require fixed entry fees or determine variable access feesbased on player characteristics. If not pre-qualified, then in block1726, the system provides a rejection notice to the player. In someembodiments, the system indicates why the player was not pre-qualifiesand/or provides additional entry-related information to the player, forexample, that the player had a characteristic of 80% and the worldrequired level of 85%, or other indicia of requirements for access to aparticular world or activity.

Assuming the player and character are pre-qualified and the player andcharacter are moved to a new virtual world, then in block 1727, thesystem determines or selects a virtual world. For example, the systemmay analyze the player's profile, determine that the player ischaracterized as 65% grinder and 35% explorer, and then match thatpre-qualified player to a virtual world limited to players with at leasta 50% grinder and 20% explorer characterization. The system may have adatabase or other data structure that maps multiple games/virtual worldto different qualifications.

Another example is a virtual world for role-players or players whoexhibit a greater “bonding metric”, and thus the system matches suchplayers to a virtual world that facilitates or encourages interactionsamong players. The system can, for example, analyze which fellow playersa given player frequently plays with, the number of communications withparticular players, and so forth, to thereby determine whether the givenplayer likes to play only with a certain group of other players or thattheir play with a certain group of players exceeds a given threshold,communicate with those players beyond a threshold, and so forth. Thesystem can thereby determine that players of this type enjoy a morecloser bond with these fellow players, as opposed to players whofrequently move from group to group, and rarely play with the sameplayers within a given week or month. In some embodiments, the system,based at least in part on identifying certain users exhibiting strongbonds with each other, may create associations between these users,automatically create “friend lists” between these users, propagate orotherwise modify exclusionary criteria between the users as furtherdescribed herein, and other similar actions to enhance the users' mutualexperience. Thus, a server could be created comprising players that aremore prone to group and bond with other players as opposed to “loners.”

The system can also analyze not only interactions of the player, and theplayer's characters, but also interaction of those characters withinmultiple different groups. Therefore, the system can, for each of theplayer's characters, track what other characters of other players withwhom that character plays. For example, a player may, when playing hiswizard character, frequently play with certain other players and theirassociated characters, whereas when the player plays his fightercharacter, he may then play with a different group altogether.Nevertheless, the commonality between that player's characters and twospecific groups week after week, would increase the bonding metric forthat player.

In block 1728 the system determines whether any statistics for thatcharacter need to be normalized or otherwise modified or adjusted. Forexample, the system determines whether the new virtual world employscharacters having statistics and values that appropriately map and arescaled to those for the character. If normalization is required, then inblock 1729 the system performs such normalization. The system mayfurther adjust or exchange currency of one virtual world with thecurrency of another virtual world based on, for example, predeterminedexchange rates, the going rate of a particular item or items within eachvirtual rate, and/or a dynamically determined exchange rate based on theextent to which players are exchanging currency. Thus, characterstransferring or otherwise accessing worlds with differing inflationrates are provided with relatively similar levels of wealth in thedifferent worlds. Other normalization techniques and factors are alsocontemplated. For example, the system may consider auction prices forparticular items, average wealth, play times, levels, the age of aworld, and other world-based criteria. In some embodiments, based atleast in part on these factors, users prior to transfer are providedwith indicia of how their various characteristics and/or items wouldchange if a user accesses a different world. A user can then confirmtheir intent to access a world if these changes are acceptable.

In block 1730, the system determines whether any equipment statisticsare to be adjusted. For example, the system may determine that certainitems that the character holds in inventory are too powerful (or tooweak) for the current virtual world, were never supported by the currentvirtual world, or have been retired or removed from the virtual world.If so, then in block 1735, the system adjusts statistics for thatequipment to help ensure that the player has an enjoyable gamingexperience in the new virtual world, without sacrificing the gamingexperience of existing players within that world.

In block 1740, the system determines whether the new character isleaving the virtual world (voluntarily, or involuntarily for failing tomeet certain qualifications, noted below). If so, then in 1745, thesystem determines whether to adjust statistics or equipment values. Forexample, the system may convert statistics for the character back tothose that the character had before joining the new virtual world,possibly with increases based on successes achieved during gameplay inthe new virtual world. Such adjustments to equipment or statistics areperformed by the system under block 1750. Alternatively, the system mayperform a conversion when the player enters another virtual world.

In some embodiments, players would maintain certain qualifications toremain in the pre-qualified virtual world or else be transferredelsewhere. For example, the system determines at a first time that aplayer satisfies a given criteria for access to a first virtual world oractivity. At a second time occurring after the first time, the systemdetermines that the player no longer satisfies the criteria. In someembodiments, the player is immediately transferred to a second world orno longer permitted access to the first world, for example, until theplayer again satisfies the criteria. In other embodiments, the player isprovided with an indicia at the second time that they no longer satisfythe criteria and, at a third time occurring after the second time, ifthe player still no longer satisfies the criteria they are then barredfrom accessing the first world, and/or transferred to the second world,etc. The system may check for such continued qualifications/thresholdsin block 1740. For example, a player might have to play a minimum amountof time each month or be moved, perhaps with one or more warnings priorto being world-transferred. As another example, players may becomedisqualified from a pre-qualified virtual world if they no longer meetqualification criteria (e.g., top 1000 DPS, healer, and tank charactersacross all game servers). In some embodiments, the system may allow acharacter to exist in a pre-qualified virtual for some threshold periodof time (e.g., 72 hours) before disqualifying the player. This wouldaddress the issue of dead worlds, etc.

Qualifications or requirements for access could be dynamically andflexibly adjusted for each world based on current world characteristicsand populations. If the world was overcrowded, the system might requirehigher standards for transfer or eliminate transfers entirely for aperiod. If the world needs more players, standards might be lowered orotherwise adjusted. Moreover, a character may become overqualified for apre-qualified virtual world and prompted to enter a more advancedvirtual world. As an example, the system may establish of hierarchy ofpre-qualified virtual worlds, such as a series of virtual worlds forraiders, each successive pre-qualified virtual world providing moredifficult and more rewarding raid content for raiders. If a characterproves to be successful in the world based on, for example, thecharacter's accomplishments in the virtual world compared to othercharacters in the virtual world, the character may be promoted to a“higher” pre-qualified virtual world. Alternatively, if the character isnot successful, the character may be relegated or demoted to a “lower”pre-qualified virtual world. In some embodiments, lists of charactersand relative achievements in various worlds such as leader boards, etc.based on various user criteria and classifications described herein aredisplayed or provided to users.

Characteristics used to qualify players and/or characters forpre-qualified virtual worlds could include, but are not limited to, playfrequency, time of play, chat frequency, chat content/style, how muchthey explore, how much they repeat the same content, how often theygroup, power or other characteristics of equipped items, class, race,title, real world characteristics, and other user and/or charactercharacteristics, classifications, and/or criteria described herein. Thesystem may maintain data structures storing characteristic informationfor different characters and analyze this information to dynamicallydetermine a pre-qualified set of characters for each pre-qualifiedvirtual world. The system may perform this analysis in real time or mayperform the analysis periodically (e.g., once per day, once per week,once per month, and so on).

Some Alternative or Additional Features

Those of ordinary skill in the relevant art will recognize that manyalternative or additional implementations of the system are possible.For example, in addition to having multiple characters, a player canhave different characters associated with different moods or play stylesfor that player. The player may be in a questing mood, and have acharacter associated with that mood. Likewise, the player may have atank character that the player typically employs when that player is ina more aggressive mood. For example, if the player had a bad day, thenthe player may wish to engage in some power-gaming with other players ina hack and slash fashion in defeating multiple monsters. However, if theplayer is more reflective, he may wish to enjoy more escapism, and thusexplore the virtual world. Further, if the player is in a more playfulmood, he may wish to engage in more role play, and then may have acharacter appropriate for such role play. Thus, the system determines,for a first character and a second character of a first user, a firstclassification for the first character associated with a first networkedactivity and a second classification for the second character associatedwith the first networked activity and/or with a second networkedactivity. The system tracks these classifications and recommendsactivities, for example based on information related to a user's mood,preferences, etc.

The system can access other engines and databases to extract furtherinformation regarding the player and other players. For example, thesystem may employ a social networking application programming interface(API), such as the Open Graph API, to access social networking data.Such external data can provide further refinement of computedcharacterizations of players.

The system can employ a progression dynamic, such as a status bar, thathelps motivate the player to complete a longer questionnaire. Such aprogression dynamic can help motivate the player to complete such longforms, where such forms gather better player data.

To help further motivate behaviors, the system can provide a medal,award or seal that is displayed on or with the player's characters in agame or other endeavor, which provides an indication to fellow playersof that player's skills in playing the game.

While described herein as enhancing online gaming, the system can beapplied to any online activity involving multiple users. For example,the system may be used for crowd sourcing, in that it may be able tohelp match similar users to help cure social ills. Thus, rather thanplaying games, the system can match users to particular causes, andallow those users to collectively work together to help with socialreform or other beneficial ends.

As another example, the system can provide a method for multiple playersto be involved in a “game” that encourages players to participate in andcreate a digital work that has value beyond the “game”. One example is a“competition” where players are encouraged or incentivized to createentries for WiKi pages on particular topics, to derive ways to solveparticular problems (such as social, ethical, environmental, or otherproblems), and so forth.

Alternatively or additionally, the system may provide indicia, presets,policies, or other predefined filters that show common statistics orpresets for players sharing common characteristics. This can allow aplayer, particularly a new player, to understand common or typicalstatistics for players sharing a common profile. For example, such apredefined filter can show statistics common for an explorer, such asaverage movement per session, average number of communications persession, average experience points or gold obtained per session, and soforth. Likewise, such filters can help define a typical role-player withhigher than average statistics for number of communications per session,reduced movement per session, greater use of emotes and other non-combatuser input commands, etc.

Alternatively or additionally, the system can provide examples on how aplayer can become a power gamer, explorer or other type. For example,the system can publish or post updates on a website regarding theaverage metrics for players characterized in each of various categories.

The system can suggest a mentor to the player, typically a fellow playerwho has achieved a certain level of expertise, and who may typify thattype of player. Thus, other players who have such expertise can hirethemselves out as a tutor. The system can provide a database with awebsite front end (or other user interface) to allow players to accessthe database of potential tutors, where such tutors may be listed basedon their user name, common type of character they play, their gamingstyle, hours played of a given game, and so forth. Such tutors may bepaid by the requesting player, and the organization running the systemcan receive a percentage of such payment.

The system may use the gathered or tracked information for many purposesbeyond those described above. For example, the gathered information maybe used to help game designers in developing future games or inmodifying existing games. Thus, a game designer may have estimated thata puzzle, quest or goal in a game would typically be solved or fulfilledwithin an estimated time. However, by analyzing data gathered by thesystem described herein, the game designer may conclude that mostplayers require a much greater time period to solve that puzzle orfulfill that quest or goal. Therefore, the game designer can modify theexisting game, or release a new game, that permits a similar puzzle tobe solved more quickly, or similar quest/goal to be fulfilled morequickly. Likewise, the game designer may determine that a greater thanaverage number of players participate in a particular activity or quest,thereby implying to the game designer that most players enjoyed thatgoal or quest more than others that may be provided within the game.Thus, the game designer can release a new version of the game, or createa new game, that includes a similar goal or quest, or employs similarthemes or creative elements from the existing goal/quest that mostplayers apparently enjoyed. Overall, the system can, in addition toproviding compatible player aggregation, provide an automated feedbackloop to game designers to permit them to analyze data and metrics fromgame play to identify strengths or weaknesses in a given game and helpguide future game development, all without the to formally query orsurvey players. Further, such a system may be embedded within oraccessed by a game and thereby employed solely for use in gatheringfeedback data to game designers, rather than for the playerclassification and aggregation described herein.

CONCLUSION

While the system is generally described above as being applicable foruse in an MMOG and particularly a fantasy-themed game, it bearsrepeating that the invention is not so limited, and can apply to notonly any game, but also to any online or real world endeavor between twoor more people. Further, while the system is generally described aboveas being employed in an on-line system involving numerous computers, andpossibly inferring that these computers are connected via cables, theinvention is readily usable in a wireless environment or even offlineperiodically. Indeed, some or all aspects of the invention areapplicable to a wireless environment where games or any other onlineendeavor is performed on portable devices, such as smart phones, cellphones, tablets, laptops or other portable devices. Further, theplayer/user analysis, profile generation, and matching can bedistributed wirelessly among multiple portable devices, and may not belimited to running on one or more stationary servers.

Unless the context clearly requires otherwise, throughout thedescription and the claims, the words “comprise,” “comprising,” and thelike are to be construed in an inclusive sense, as opposed to anexclusive or exhaustive sense; that is to say, in the sense of“including, but not limited to.” As used herein, the terms “connected,”“coupled,” or any variant thereof means any connection or coupling,either direct or indirect, between two or more elements; the coupling orconnection between the elements can be physical, logical, or acombination thereof. Additionally, the words “herein,” “above,” “below,”and words of similar import, when used in this application, refer tothis application as a whole and not to any particular portions of thisapplication. Where the context permits, words in the above DetailedDescription using the singular or plural number may also include theplural or singular number respectively. The word “or,” in reference to alist of two or more items, covers all of the following interpretationsof the word: any of the items in the list, all of the items in the list,and any combination of the items in the list.

The above Detailed Description of examples of the invention is notintended to be exhaustive or to limit the invention to the precise formdisclosed above. While specific examples for the invention are describedabove for illustrative purposes, various equivalent modifications arepossible within the scope of the invention, as those skilled in therelevant art will recognize. For example, while processes or blocks arepresented in a given order, alternative implementations may performroutines having steps, or employ systems having blocks, in a differentorder, and some processes or blocks may be deleted, moved, added,subdivided, combined, and/or modified to provide alternative orsubcombinations. Each of these processes or blocks may be implemented ina variety of different ways. Also, while processes or blocks are attimes shown as being performed in series, these processes or blocks mayinstead be performed or implemented in parallel, or may be performed atdifferent times. Further any specific numbers noted herein are onlyexamples: alternative implementations may employ differing values orranges.

The teachings of the invention provided herein can be applied to othersystems, not necessarily the system described above. The elements andacts of the various examples described above can be combined to providefurther implementations of the invention. Some alternativeimplementations of the invention may include not only additionalelements to those implementations noted above, but also may includefewer elements.

Any patents and applications and other references noted above, includingany that may be listed in accompanying filing papers, are incorporatedherein by reference. Aspects of the invention can be modified, ifnecessary, to employ the systems, functions, and concepts of the variousreferences described above to provide yet further implementations of theinvention.

These and other changes can be made to the invention in light of theabove Detailed Description. While the above description describescertain examples of the invention, and describes the best modecontemplated, no matter how detailed the above appears in text, theinvention can be practiced in many ways. Details of the system may varyconsiderably in its specific implementation, while still beingencompassed by the invention disclosed herein. As noted above,particular terminology used when describing certain features or aspectsof the invention should not be taken to imply that the terminology isbeing redefined herein to be restricted to any specific characteristics,features, or aspects of the invention with which that terminology isassociated. In general, the terms used in the following claims shouldnot be construed to limit the invention to the specific examplesdisclosed in the specification, unless the above Detailed Descriptionsection explicitly defines such terms. Accordingly, the actual scope ofthe invention encompasses not only the disclosed examples, but also allequivalent ways of practicing or implementing the invention under theclaims.

To reduce the number of claims, certain aspects of the invention arepresented below in certain claim forms, but the applicant contemplatesthe various aspects of the invention in any number of claim forms. Forexample, while only one aspect of the invention is recited as ameans-plus-function claim under 35 U.S.C §112, sixth paragraph, otheraspects may likewise be embodied as a means-plus-function claim, or inother forms, such as being embodied in a computer-readable medium. (Anyclaims intended to be treated under 35 U.S.C. §112, sixth paragraph,will begin with the words “means for”, but use of the term “for” in anyother context is not intended to invoke treatment under 35 U.S.C. §112,sixth paragraph.) Accordingly, the applicant reserves the right topursue additional claims after filing this application to pursue suchadditional claim forms, in either this application or in a continuingapplication.

I/We claim:
 1. A method for characterizing users of networked computergames, the method comprising: identifying one or more characteristics ofa first user of a first networked computer game; automaticallyidentifying, with computer hardware comprising one or more processors,one or more actions performed by the first user, wherein the first useremploys a data processing device in communication with the networkedcomputer game via a public computer network; determining a firstcriterion based at least in part on the one or more characteristics ofthe first user and the one or more actions performed by the first user;associating the first criterion with the first user; identifying one ormore characteristics of one or more second users of the first networkedcomputer game; automatically identifying, with computer hardwarecomprising one or more processors, one or more actions performed by theone or more second users, wherein the one or more second users employone or more data processing devices in communication with the networkedcomputer game via the public computer network; determining one or moresecond criterion based at least in part on the one or morecharacteristics of the one or more second users and the one or moreactions performed by the one or more second users; associating the oneor more second criterion with the one or more second users; analyzingthe first criterion and the one or more second criterion to determineone or more relationships between the first criterion and the one ormore second criterion; and providing, based at least in part on the oneor more relationships between the first criterion and the one or moresecond criterion, the first user with an option related to a networkedcomputer game.